Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Update: Forum Guidelines & Code of Conduct

    QIODevice and minimum data chunk

    General and Desktop
    3
    10
    3771
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      p-himik last edited by

      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?

      1 Reply Last reply Reply Quote 0
      • G
        goetz last edited by

        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.

        http://www.catb.org/~esr/faqs/smart-questions.html

        1 Reply Last reply Reply Quote 0
        • M
          mlong last edited by

          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.)

          Software Engineer
          My views and opinions do not necessarily reflect those of anyone -- living or dead, real or fictional -- in this universe or any other similar multiverse node. Void where prohibited. Your mileage may vary. Caveat emptor.

          1 Reply Last reply Reply Quote 0
          • G
            goetz last edited by

            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).

            http://www.catb.org/~esr/faqs/smart-questions.html

            1 Reply Last reply Reply Quote 0
            • P
              p-himik last edited by

              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 > >.

              1 Reply Last reply Reply Quote 0
              • M
                mlong last edited by

                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.

                Software Engineer
                My views and opinions do not necessarily reflect those of anyone -- living or dead, real or fictional -- in this universe or any other similar multiverse node. Void where prohibited. Your mileage may vary. Caveat emptor.

                1 Reply Last reply Reply Quote 0
                • P
                  p-himik last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • G
                    goetz last edited by

                    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.

                    http://www.catb.org/~esr/faqs/smart-questions.html

                    1 Reply Last reply Reply Quote 0
                    • P
                      p-himik last edited by

                      So with QByteArray i get more certainty, right?

                      1 Reply Last reply Reply Quote 0
                      • G
                        goetz last edited by

                        Whatever you define as "certainty"...

                        http://www.catb.org/~esr/faqs/smart-questions.html

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post