Socket : how to deal with traffic jam ?

[bangkok]

I have a socket server, and several clients on the local network.

The clients connect, send a query (SQL), the server receives the query, processes the query, and sends back the result. Clients cut the connexion. And start again. etc.

It's working fine.

Classic architecture :

server side :
accept connections on 8192 with message "Connection"
read from socket theIP until return with message "contacted"

client side :
open socket to lip with message connected
write "someData"&return to socket theSocket
read from socket theSocket until "#" with message "incoming"
close socket theIP

But I fail to understand what could happen if the server receives too many connexions ?

While working to process a SQL query (let's say, the socket server wait severals seconds for the SQL server to send the result), another liveCode client sends another query ? How LiveCode can deal with this situation ?

There is like a buffer ? First in, first out ? Or data could be lost ?

Or it would be better to use a RunRev CGI server ? Each client sends a query, which opens for each one thread, right ? problem solved ?

[Janschenkel]

LiveCode is inherently single-threaded, except for a few places like socket communication. In essence, the engine will buffer all incoming and outgoing data and read/write it on separate threads if you use the 'with message' option. So none of the requests are lost, just delayed. However, every bit of LiveCode script execution happens on the same thread, including database access. So your script can't start to handle another request until the current request is processed. As long as you keep the units of work small enough, it can handle quite a few requests without noticeable slow-downs for the client users.
LiveCode Server uses multiple processes, one for each request, relying on the server machine operating system caching mechanism to keep the core engine in memory to aid startup times. This means it can scale up as the server platform grows (the OS can decide to run two instances on different cores or CPU's). But the flipside is that every request has the overhead of opening a new database connection, and you have to be more careful about correctly handling concurrent data access.
As usual, testing to find the limits is the only way to be sure...

Jan Schenkel.

[bangkok]

Thanks Jan.

It's clearer now.

In any case my question was theoritical (I don't have, yet, issues with too many connexions).