QIODevice and minimum data chunk

[p-himik]

Actually i'm using QSslSocket but i think that answer to my question depends on QIODevice.
When i send data through QSslSocket and if data length is no more than 4096 bytes readAll() for receiving socket returns all data.
If sent data is longer than 4096 bytes than receiving socket receives data in chunks of 4096 bytes.
The question is: does this length machine-dependent? And what is the minimal chunk size?

All i want is to send large amounts of data and parse them with client's app. So i decided to send some tags along with it (messageId:messageLengthmessageData</messageId>). Opening tag consists of three QChars and two ints. Will my client receive at least opening tag for evaluating message's length under all circumstances?

[goetz]

Using TCP connections (which are the base of the SSL sockets) you cannot predict reliably the size and amount of chunks which your payload will be cut into. So, unfortunately no, you cannot even rely on your opening tag to be transferred in one chunk.

You might have a look at the [[Doc:QXmlStreamReader]] class, it is capable of incremental parsing. But you need to transfer complete XML documents in that case.

[mlong]

What's your reasoning for wanting to send the multiple message length tags? What is the problem you're wishing to avoid? If you can clarify that, then there might be some helpful suggestions which can help create a better alternate solution (or at least alleviate some fears about shortcomings in the toolkit.)

[goetz]

I suspect the reason is to simplify the message handling on the receivers side. One solution that comes into mind, is to use a [[Doc:QTextStream]] on top of the socket. One could send a message header, including the message length in a single line - one can use canReadLine() then to check whether a complete line is in the buffers. Based on that length the subsequent reads can be constructed. If possible by the data stream, another solution could be to insert one or two empty lines to signal the end of a message (just like the HTTP protocol separates header and body).

[p-himik]

Yes, Volker, you're right about tags.
I don't think that QTextStream will fit my needs since most of the data is binary.
For example if messageId is 10001 the message itself is QMap< QMap< qint32, QString > >.

[mlong]

You should consider using "QDataStream":http://developer.qt.nokia.com/doc/qt-4.7/qdatastream.html then, with the same design as Volker mentioned above.

[p-himik]

I use it but in rather different manner. I write all data (including headers and message's size) with QDataStream to QByteArray. And then send this array through QSslSocket. It's convenient to pass then this QByteArray to function that is relevat to message's ID.
And what will happen to, let's say, QMap when QDataStream is writing to it and QIODevice associated with this QDataStream is unexpectedly closed?
P.S.: Sorry for my English. While writing last sentence i felt like i totally need to read about grammar.

[goetz]

QDataStream expects that the data for a single read operation using operato>> is completely available. It does not recover from premature end of data, may it caused by an unexpected close of the connection or by a partial transmission. The result of a read past the end of the available data is undefined, in case of your QByteArray, it's most likely that it is truncated.

[p-himik]

So with QByteArray i get more certainty, right?

[goetz]

Whatever you define as "certainty"...