QTcpServer with multiple persistent connections
-
@l3u_ said in QTcpServer with multiple persistent connections:
@kshegunov But after all, we can still be sure that a message is processed completely by using QDataStream transactions, can't we?
Well, yes. But you're not protected from a malformed message (i.e. some client you didn't write sending you a ridiculous message).
Connecting my server using telnet from a console, the JSON greeting is prepended by an additional character, so I think the datastream also adds some header and knows if it's complete?
Yes, it adds the
QByteArray's size before sending the actual contents of the byte array. However you have no way of knowing if this size (or the data) isn't corrupted somehow. That's really rare, but it's a possibility.For example we don't check the byte array's size before trying to read the data. If someone sends you an integer indicating a message of 10GB, the code will just eat it. It doesn't check if that's too big.
If I read the code correctly, the chat example makes sure that a whole message is received (and the socket buffer is emptied after reading it out) and tries to parse the JSON data inside it. If it's actually JSON, and it's valid, some action is triggered, if not, nothing is done – but the buffer is still emptied. Is this correct?
That is correct.
@kshegunov Okay, then I'm safe. It's a protocol to be used by two or three computers in a LAN, and everybody using it wants it to function – so nobody will try to fake a message or trick it with wrong headers.
I protect the integrity against whatever may go wrong with a checksum: Each change request contains a checksum the whole data has to have afterwards. If the checksum is correct after a client applied the change, everything is fine. If not, the connection is closed and the client is told to re-connect, as a syncing with the server is done when a new client connects. Ans this one also contains the checksum verification.
At least, I hope that I'm safe this way ;-)
-
@kshegunov Okay, then I'm safe. It's a protocol to be used by two or three computers in a LAN, and everybody using it wants it to function – so nobody will try to fake a message or trick it with wrong headers.
I protect the integrity against whatever may go wrong with a checksum: Each change request contains a checksum the whole data has to have afterwards. If the checksum is correct after a client applied the change, everything is fine. If not, the connection is closed and the client is told to re-connect, as a syncing with the server is done when a new client connects. Ans this one also contains the checksum verification.
At least, I hope that I'm safe this way ;-)
-
@kshegunov Nice! Man, you all really, really helped me with this. I never did TCP stuff until now, but I'm pretty sure I can implement it in a proper way for my usecase with your help :-)
