QTcpServer with multiple persistent connections

JonB

@kshegunov
I realise @VRonin's reply is the way to go, and have already upvoted that.

However, your

as you already committed a heinous crime against the system already: you read 1GB off the hard disk and send it directly to the socket. ;)

? My "TCP clients" in this case were the ones who read data off the disk and sent them to my server. How they did that is up to them, I have no knowledge, where's the crime? What's that got to do with your approach of having the server receive the 1GB into a memory buffer? And at least the clients, if they did read into memory, only did 1GB each. The server services 100 clients, they're all in the process of sending 1GB each, my server needs 100GB memory.... :(

kshegunov

I was just teasing. If you don't control the client, then what @VRonin wrote is the way to go.

l3u_

@JonB I think what he wanted to say is that your protocol shouldn't allow sending huge packets of data in one big piece at all, and that – if you want to handle such amounts – you will have to implement it in the proper way so that everything is fine. Because if you send 1 GB to a socket using the default behavior (which will probably result in the reveiver's socket buffer filling up to 1 GB until you can read it out), you will have to read it into memory before. And you shouldn't have done that in the first place.

l3u_

@VRonin @kshegunov My stuff is far from finished, but at this point, I can say that this forum post and esp. the chat example helped like 100 times more than the official docs.

I think the chat example really should be part of the docs, as a more sophisticated example, and one for persistent connections. The fortune cookie example is nice when it comes to a very simple, one-time-use one-way connection. But somebody like me not having programmed TCP stuff at all until now simply can't figure out how to implement a bidirectional communication with multiple clients from it.

I'm a big step closer to being able to implement what I need thanks to your help and work, and I'm pretty sure I can learn quite a lot about TCP conenctions and handling them here :-)

JonB

@l3u_
I have written TCP client/server in previous products to allow transfer of files. They seem to have worked fine for years. Neither the client nor the server read the entire file into memory to send or receive. That's all I meant.

Because if you send 1 GB to a socket using the default behavior (which will probably result in the reveiver's socket buffer filling up to 1 GB until you can read it out),

Umm, will it?? I don't think so... Pipes wouldn't do well...

l3u_

@JonB I'm totally fine with everything and everybody here – I'm the one that surely has the least experience with all this here ;-) And I won't be transferring stuff that is bigger than a few hundred characters of JSON data, so the problem is surely interesting, but I don't think I have to worry about it in my case.

kshegunov

@JonB said in QTcpServer with multiple persistent connections:

Umm, will it?? I don't think so... Pipes wouldn't do well...

Probably, yes. Qt has its own buffering on top of the socket layer, so unless you change that, by default the socket's buffer will accommodate it provided you have enough memory.

@l3u_ said in QTcpServer with multiple persistent connections:

I'm the one that surely has the least experience with all this here

Don't worry, give it a decade or two and you'd be the one giving the advice. ;P

JonB

@kshegunov said in QTcpServer with multiple persistent connections:

Qt has its own buffering on top of the socket layer

So if you then use socket "transactions" on top of the socket, I read that as doing the buffering in memory. Do you mean the transactions have to add another layer of buffering, or do they use whatever the QTcpSocket is already using?

kshegunov

@JonB said in QTcpServer with multiple persistent connections:

So if you then use socket "transactions" on top of the socket, I read that as doing the buffering in memory. Do you mean the transactions have to add another layer of buffering, or do they use whatever the QTcpSocket is already using?

They use the QAbstractSocket's buffer directly. Think of the transaction as only adding atomicity to the reading from the Qt's buffer. They do stuff similar to what @VRonin wrote about splitting your big data chunk: try to read it in the known format, if that fails, rewind the buffer's pointer. If it succeeds cut the internal buffer with what you read.

Dick Balaska

Sorry to jump in late here, but I've been grooving on WebSockets lately
(a stupid name for a good protocol). Very easy to setup and use in Qt 5. Connect a couple of signals and slots and you can reliably send and receive text and/or binary data. You can ignore the grind of TCP/IP and just mostly deal with your text.

kshegunov

That is true. There are 2 conditions to do so, however:

You want to commit to the websockets protocol, which isn't always the case.
You are willing to pull a module outside of qtbase, which is fine most of the time.

To expand on 1:
In the project I'm currently working on I have to support multiple protocols, so websockets does me no good. You may be surprised, but that case is more common than not.

l3u_

@Dick-Balaska Hey, thanks for the hint with WebSockets! I never heard about this until now. At first sight, it looks promising, because it already has the methods I need for sending and receiving text (I use JSON documents for my communication).

But would have using it an actual benefit for my use-case, after already having it got to work? What I did until now is (and it was surprisingly easy to implement it, as soon as someone points you towards the right way):

Writing an abstract class that cares about the data transmission and receiving, using QByteArray and QDataStream, similar to the chat example approach . It provides a sendMessage(const QString &message) function, and reads incoming messages, calling a virtual handler
Create a client derived from it that can connect to a server
Create a server that manages an object derived from it for each connection

So … am I right that the only thing I could have cheaped out using WebSockets is that abstract class, because the WebSocket classes already have functions for sending and receiving text?

Dick Balaska

@l3u_ If you have already hardened [1] your QTcpSocket implementation, then there's no reason to switch, except for maybe ease of SSL support.
For new work, these days I try to use WebSockets. I, too, use JSON. Each asynchronous message is just a command token followed by a JSON string.

[1] You handle message fragmentation and reconnects, right?

l3u_

@Dick-Balaska said in QTcpServer with multiple persistent connections:

[1] You handle message fragmentation and reconnects, right?

Of course I don't – or at least, I don't know – or I'm not sure ;-)

Would you please explain what you mean? If a "reconnect" is loss of a client connection followed by a new connect, I handle it (the client is removed from the server's client list as soon as it disconnects and is simply added like a new one when it reconnects).

If "message fragmentation" is that "you can't expect all data to arrive in one piece", I think this is already handled by the chat example (cf. ChatClient::onReadyRead()).

I don't need encryption and such, the protocol will only be used in a closed LAN consisting of two or three computers, the data itself is not confidential, and I also don't need to protect against manipulation etc. (somebody trying this would shoot himself in the foot as the program probably wouldn't work as expected in this case).

Dick Balaska

@l3u_ I see class ChatClient referenced in two examples (linux Qt 5.11.2), bluetooth, which I don't think you're doing, and WebChannel, which actually sits on top of WebSockets. So, I'm not sure what your base is.

WebSockets guarantees you get a whole message at a time. A regular socket (QTcpSocket) you just know you have x bytes available and it's up to you to frame them in a message. (Like http knows that \n\n is the end of the request headers).
Clearly you're well beyond that.
If you're unsure about message fragmentation, make a class with a >2k byte object and see if you get it in one message. (hardwired lan TCP is 1536 bytes per packet. Wifi is about 400 bytes per packet.)

kshegunov

@Dick-Balaska said in QTcpServer with multiple persistent connections:

I see class ChatClient referenced in two examples (linux Qt 5.11.2), bluetooth, which I don't think you're doing, and WebChannel, which actually sits on top of WebSockets. So, I'm not sure what your base is.

Scroll up. The OP is using as a base the WIP example from the wiki I sourced in my first post.

@l3u_ said in QTcpServer with multiple persistent connections:

If "message fragmentation" is that "you can't expect all data to arrive in one piece", I think this is already handled by the chat example (cf. ChatClient::onReadyRead()).

Yes, this is correct.

Dick Balaska

@kshegunov said in QTcpServer with multiple persistent connections:

Scroll up. The OP is using as a base the WIP example from the wiki I sourced in my first post.

Ok. Wrapping "read the socket" in a transaction is a neat trick. But, hmm, it determines end-of-message-received by whether it can parse valid JSON out of what it has. It seems to me that if you send a malformed message, the socket becomes dead. There is no way to clear the existing buffer. It will continue growing the buffer ad infinitum. I'd rather see it buffer until it receives a marker like \0\0, with a limit of 64KB on a message. Then if the JSON doesn't parse you can note the error and move on. Unless there is some application level feedback (ACK) involved, so the client can kill and restart the socket, neither side will know this socket is on its way to tipping over the app.

I know, you shouldn't be sending malformed JSON, but doing so shouldn't be fatal.

kshegunov

@Dick-Balaska said in QTcpServer with multiple persistent connections:

But, hmm, it determines end-of-message-received by whether it can parse valid JSON out of what it has.

This is incorrect. It determines end-of-message based on the QByteArray it receives. This isn't strictly a text protocol, as the buffer's size is known beforehand (you have QDataStream with QByteArray on both sides). If the JSON parsing (after the message is read) fails, then the server just continues its merry way, it doesn't even report the error, which it probably should ...

kshegunov

PS.
You raise a good point for the general case, however - how to validate messages that come through a binary stream. But I fear this is a topic that goes beyond the purpose of this rather simple example.

l3u_

@kshegunov said in QTcpServer with multiple persistent connections:

But I fear this is a topic that goes beyond the purpose of this rather simple example.

Keep on with your conversation if you don't mind – I (and everybody else reading this) is definitely learning all the stuff I wished to find somewhere before starting my project!