Multi-user server connection handling I'm writing a program and I have a server that needs to be able to handle multiple client connections at once doing many different things.

I'm using the Qt library, so I handle new connections like this:

In the server constructor:

Server::Server(QObject* parent): QObject(parent)
{
  connect(&amp;server, SIGNAL(newConnection()), //&amp;server is a QTcpServer object
          this, SLOT(acceptConnection())); 
  qDebug() &lt;&lt; "[" &lt;&lt; currentTime() &lt;&lt; "] " &lt;&lt; "Server started.";
  server.listen(QHostAddress::Any, PORT_NUMBER);
  qDebug() &lt;&lt; "[" &lt;&lt; currentTime() &lt;&lt; "] " &lt;&lt; "Server listening.";
}


The acceptConnection slot:

void Server::acceptConnection()
{
  client = server.nextPendingConnection(); //client is a QTcpSocket* object

  connect(client, SIGNAL(readyRead()), //When there is data to be read
    this, SLOT(startRead()));
}


The startRead slot:

void Server::startRead()
{

    char serverReceiveBuf[65536]; //A buffer for the data sent to the server
    client-&gt;read(serverReceiveBuf, client-&gt;bytesAvailable());
    handleConnection(serverReceiveBuf); //Do something with that data
}


I'm not going to give the handleConnection function because it's a bit long and I don't think it's necessary for the question.

My worry is latency. If I have one or two users, it's fine. But I haven't tested many concurrent users. There's a synchronization signal sent by the client that asks the server to verify the data the client has matches the data on the server. I'm sending this request every 250 ms, so with a few more concurrent users the client may end up waiting too long every 250 ms because of the other clients sending in synchronization requests.

At least, that's what I believe. Qt is pretty powerful, but I'm not entirely sure if when a signal is received that a new thread is automatically created to handle the connection. If I'm not mistaken, the current way I handle connections involves queueing, so that when the server receives a signal it'll process the requests in the order received. It's important to note that I don't call client-&gt;close() until the client terminates the connection themselves, so once client = server.nextPendingConnecting(); is called client will always exist until the client terminates it.

Is this a good way of handling multiple connections, given that I'll be regularly having users send synchronization requests often? If not, how should I handle the connections instead?
I was not able to find this question on SO, so let me try to give an answer here:

A general idea:

Depending on the nature of the data your are synchronizing, it might be better that the server sends out a synchronization signal and the clients synchronize to the data received from the server. 

Specifics to the code of the question

I see two problems in the slot function acceptConnection() according to the documentation: 


the function nextPendingConnection() may return 0. This may lead to a problem with the following connect statement. You should check for 0 response.
nextPendingConnection() will not return the exact same connection for which the signal was sent, it just returns "the next one". This may lead to a problem when multiple connections are made at the same time, or your code cannot handle one of them in time. It might be better that you handle all pending connections in a loop.


With these additions your code would perhaps look like this:

void Server::acceptConnection()
{
   while(client = server.nextPendingConnection()) //client is a QTcpSocket* 
   { 
      connect(client, SIGNAL(readyRead()), this, SLOT(startRead()));
   }
}


This brings us directly to the next problem: the client variable - I assume that this is a member variable of the Server class - will be overwritten for each new connection.

The Better approach is to follow the advice in the documentation and override incomingConnection(). We could subclass QTcpSocket and implement the handleConnection() functions from there. The documentation describes what the base class function normally does.