LiveCode Forums.

Hello everyone.

I'm running a cloud-server which handles thousands of TCP socket connections but it seems to just die when socket connections goe's beyond 4000 ~. For now, I'm splitting the work by creating multiple workers that handle 1000 connections each and each of them connects to the main server that connects them all together.
My question is, is there a limit to the number of socket connections that LiveCode can have? I've seen other languages that have a limit of 4096 so i search /engine/src/opensslsocket.cpp and found . If that's the case, will it help if I increase that amoung and recompile LiveCode? is there a reason for having that limit?

PS: I'm using LiveCode 6.7.11 Indy but I have tested this with LiveCode 9.0.4, same results. Also, I found nothing about this in the docs.
Thank you.

Many factors can contribute to this. What OS version, RAM, etc?

16 GB ram 8 core Xeon processors , windows server 2012. I don't think it's a hardware issue, ram usage rarely gets beyond 300mb of the standalone and CPU usage is around 10% untill it reaches the limit ( 4000 ~ sockets ) at that point it goes at 30% for some time and then crashes. Also I don't think it's an OS issue since the multi server solution as I described above works normally .

Are your socket handlers using the callback option?

Yeah I have added a callback method to all socket operations, open sockets, read from sockets and eventually write to socket (even though I don't really use this one but as it turned out write to socket was blocking also).

"livecode/engine/src/opensslsocket.cpp" From what I can understand from this, maximum socket size has been set to 16 bits so that answers my initial question. This could easily be changed to 32 bits I guess so the question now is, why not? I can't figure out why that limitation exists.

That's a good question. Perhaps submit a pull request with the change?

@zaxos: The READ_SOCKET_SIZE determines how much extra space is added to the current read buffer for a given socket beyond that needed to empty the sockets system buffer. e.g. if the current read buffer contains 1024 bytes, and the total size needed to empty the system buffer is 4096, the engine will allocate 4096 + READ_SOCKET_SIZE bytes to try and ensure it has enough room for more reads without reallocating... i.e. It has nothing to do with the number of sockets you can have.

As far as I'm aware there aren't any fixed limits on the number of sockets LiveCode can allocate - although the crash you are getting strongly suggests that an OS call *is* failing at some point but is unchecked. If you can submit a bug report with a simple stack which replicates the crash with lots of sockets then we can at least make things fail gracefully.

There are hard limits to the number of sockets Windows can allocate - https://sockettools.com/kb/maximum-socket-connections/ - although as mentioned in the article some aspects are configurable.

So a couple of questions:

How many concurrent socket connections can you achieve when you split things up so you have 1000 or so per LiveCode process?

How is the main server communicating with the workers and outside world... I take it that isn't written in LiveCode...

I'd point out that the worker farming method is probably better than a single LiveCode process handling them all as then you take advantage of multiple CPU cores - i.e. performance is likely to be better (this is presuming that the connection to the marshalling process doesn't dominate the workload though).

@LCMark: do you know offhand if socket handing on Linux is any better for this?

@FourthWorld: I suspect its swings and roundabouts. Both OSes have limits in various places (mostly configurable - Linux has an per-process file-descriptor limit, for example), and both will be limited by amount of memory (either kernel or user space); and that of the performance of the algorithms they use internally to manage very very large numbers of OS objects.

Thank you for the answer LCMark. It proves a lot besides my lack of understanding for c++.
I have tried the registry tweaks from the link you provided but it seemed to make no difference. Here are the facts that I have so far:
- The server seems to crash after 4000~ if its a standalone or just freezes if it's running inside the IDE.
- I am getting A LOT of socket errors and after some packet sniffing I found out that the connection is being reset client side from some countries ( their ISP? ). I have a feeling that these might be related to the crashes since LC doesn't seem to be handling socket errors very nicely ( sometimes sockets won't close after an error, even if I issue "close socket xxxx" )
- Workers had no crashes on me so far though ( even with the socket errors ) although it is fair to say that they handle much less workload than a single standalone.

Anyway, I'm moving away to a REST-based system as it seems to be much more reliable and accurate in my case. I will only be keeping the socket server around for client validation. That said, I will be doing some more tests and debugging that might help us identify the problem and report back.
Thank you.

EDIT: Also i am getting a few "empty" socket errors as you can see in the picture. Both socket and error code parameters are empty for some reason.

What is your "REST-based system" written in?

The REST API is also written in live code ( using lc server ).

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.