QTcpServer - get the correct QTcpSocket

[elcuco]

I am wrigin a small server in Qt4. The "protocol" is quite simple:

client sends "cmd1" server responds "ok"
client sends "cmd2" server responds "ok"
client sends "cmd3" server responds "fail"

I have a few doubts about the best approach to this:
each time a new connection is made, and new callback will be called from which I `get tcpServer->nextPendingConnection()` and. The problem I face is that if I have several connections, I am not sure how to save that socket. My first implementation saved the socket in the class - but this kills the concurancy and only one client can connect.

My second implementation is doing this trick:

void LogicCommunication::on_data_read()
{
	QTcpSocket *socket = qobject_cast<QTcpSocket*>(sender());
	QString s = socket->readAll();
 
	QStringList args = s.split(',');
	QString     command = args[0];
	if      (command == QLatin1String("layout")) 
		parseNewLayout(s,args,socket);
	else if (command == QLatin1String("play"))
		parsePlayFile(s,args,socket);
	else if (command == QLatin1String("stop"))
		parseStop(s,args,socket);
	else 
		emit errorInProtocol(s,"No valid command sent",socket);
}

void LogicCommunication::on_data_read()
{
	QTcpSocket *socket = qobject_cast<QTcpSocket*>(sender());
	QString s = socket->readAll();
	
	QStringList args = s.split(',');
	QString     command = args[0];
	if      (command == QLatin1String("layout")) 
		parseNewLayout(s,args,socket);
	else if (command == QLatin1String("play"))
		parsePlayFile(s,args,socket);
	else if (command == QLatin1String("stop"))
		parseStop(s,args,socket);
	else 
		emit errorInProtocol(s,"No valid command sent",socket);
}

To copy to clipboard, switch view to plain text mode 

In each command I emit a signal, I also pass the socket and the remote side (the GUI in my case) can then use that socket to send information back. I am not really happy about this solution, since this means that the GUI needs to know about the connection media (QTcpSocket).

The other alternative I am thinking of is saving the socket in a separate thead, but I am not happy about it. Who needs threads for this code?

Do I have another alternatives? What would you guys do?

[victor.fernandez]

You may use a QHash<QTcpSocket*,Command>. In order to keep track of the status of each client, use the command pattern. Anyway, in my opinion you should use threads for this. The code would be cleaner and you wouldn't have the risk of a slow client freezing your GUI.

[wysota]

Why would a slow client freeze the gui if the client is on another machine? Using threads is a bad idea here, it doesn't make the code any cleaner and it slows down the whole application and makes it more complex.

[elcuco]

Actually, the "server" is on on localhost... let me explain:

This customer has a client server application written in C#. They decided to port it to linux, nice. The server work on mono, and the client does not, because it displays video. Ok, lets spit the client into two new parts:

[server]   <-> [client]
[server]   <-> {[backend (C#) ]  <-> [frontend (Qt4)]}

[server]   <-> [client]
[server]   <-> {[backend (C#) ]  <-> [frontend (Qt4)]}

To copy to clipboard, switch view to plain text mode 

Now the communication between the front end and backend will be done on TCP sockets. Both sides are on "localhost".

Each time I talk to the customer and ask for implementation ideas, he keeps talking about threads and stuff. He is a on time C/win32 guy who does not fully understand that my whole application is single threaded yet (he did not overview the code yet), and that the model that Qt4 imposes by default is asynchronous callbacks.

Anyway, my idea was to emit signals which contain the socket, back and forth between the front end and backend, or maybe the front end can directly write the messages to the socket. I am looking for other alternatives (create a new separate class for each connection might be a good idea, but it has a lot of overhead).

[wysota]

Actually, the "server" is on on localhost..

It doesn't matter, it's a different process.

Each time I talk to the customer and ask for implementation ideas,

First rule of software development - never let your client anywhere near any implementation details. Either you are creating the application or he is.