HiveBrain v1.2.0
Get Started
← Back to all entries
patterncppMinor

Multi-user server connection handling

Submitted by: @import:stackexchange-codereview··
0
Viewed 0 times
handlingmultiuserserverconnection

Problem

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(&server, SIGNAL(newConnection()), //&server is a QTcpServer object
          this, SLOT(acceptConnection())); 
  qDebug() << "[" << currentTime() << "] " << "Server started.";
  server.listen(QHostAddress::Any, PORT_NUMBER);
  qDebug() << "[" << currentTime() << "] " << "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->read(serverReceiveBuf, client->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 proces

Solution

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.

Code Snippets

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

Context

StackExchange Code Review Q#57698, answer score: 2

Revisions (0)

No revisions yet.