LiveCode Forums.

REST = HTTP = sockets.

It would seem the difference between the working and non-working systems isn't sockets, but the protocol used on top of sockets.

I'm not sure what you by that. I understand HTTP requests use sockets but my point was that I no longer utilize a constant connection with the clients but instead the clients make calls to URLs in a predefined interval to indicate their status. In my previous setup the clients had to :
- Connect to the main server .
- Get a free port from the main server.
- Disconnect from the main server and connect to the worker they just received.
- Send their credentials and login.
- Send their status to the worker.
Server side also :
- Main server accepts connections on 2 ports, one for the workers and one for the clients.
- Main server has to keep track of the connected clients on each worker to make sure we don't overload them.
- Workers have to exchange data with the main server regarding the client status.
- I have to combine all of that data and send results back to the clients.
And much much more that overcomplicate things while with the restfull system I just make a simple url call with an API key attached to it. The downside to this is only that k don't have "live" data which means that I have a window of 2 minutes of "wrong data. Yes I understand I could'v gone to REST directly instead if creating the main server/worker solution and I WISH I knew back then... Also I understand I could use the current server and just close the connections instead of maintain them, but I see no point to it.
So to summarize , unless accuracy to second is needed ( like a chat application ? ) I would propably go for a REST solution next time. Hopefully that post saves time for someone else.

Also regarding my initial post, if LC was not crashing after some point, I wouldn't have created the main server/worker solution.

Worker pools are a common solution to high-load requirements. But if load is low enough that REST works without that proxy, it's worth exploring why. Protocol choice is ideally a function of fitness for the task at hand, rather than as a means of handling limitations unrelated to the nature of the transaction itself.

If HTTP's request-reply format is a good fit, and you have a good solution in place now, I guess it's all good.

If reverse proxy is needed again down the road, at least you have the experience to handle that well.

And if nothing else, this seems a case where we've learned that keeping sockets open that aren't needed for the nature of the transaction can saturate resources.

And if nothing else, this seems a case where we've learned that keeping sockets open that aren't needed for the nature of the transaction can saturate resources.

Indeed I've learned so much invaluable information in the process ( and still learning ) that will definitely be an asset in the future. Currently, I ended up using a mixture of both the REST logic and the constant socket connections ( HTTP for storing/loading data and sockets just for notifying the clients if there is an update) which seems to be the most efficient way to handle my situation

zaxos wrote: Fri May 24, 2019 10:15 am

And if nothing else, this seems a case where we've learned that keeping sockets open that aren't needed for the nature of the transaction can saturate resources.

Indeed I've learned so much invaluable information in the process ( and still learning ) that will definitely be an asset in the future. Currently, I ended up using a mixture of both the REST logic and the constant socket connections ( HTTP for storing/loading data and sockets just for notifying the clients if there is an update) which seems to be the most efficient way to handle my situation

That's a valuable life lesson I'm still learning myself. We gravitate toward the idea of the One Perfect Solution For All Things, but in practice I find the best solution for a given task will vary according to its unique requirements.