[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: How to move large data inside a protocol over tcp using Qt/KDE?
From:       Thiago Macieira <thiago () kde ! org>
Date:       2008-09-19 16:41:46
Message-ID: 200809191841.46627.thiago () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Matthew Woehlke wrote:
>Thiago Macieira wrote:
>> Matthew Woehlke wrote:
>> That's how it works.
>>
>> The sockets are non-blocking, always. And when the function doing the
>> reading (QAbstractSocketPrivate::canReadNotification()) is called, it
>> will read until it gets a -1 EWOULDBLOCK. When it gets that, it emits
>> readyRead().
>
>So Qt is doing its own buffering? That makes sense (and explains why Qt
>can "know" how many bytes there are). So I think for Friedrich's case,
>he'd want to check at each readyRead() if there is a full message, and
>not read until then (when he can safely read in the whole message).
>
>...which doesn't solve the problem of knowing you have a full message.
>Obviously, sticking size in front is the usual way to do it, but that
>means the message has to be serialized in its own buffer before sending
>it, so the size is known. Any clever ways to do that?

You can peek.

Peeking is basically the same as reading, except that you can do it again.

Or, another way to see it, is that you read, then you keep in your own 
buffer until you have a complete message. But, with peeking, Qt does the 
buffering for you.

>I'm coming up with: write a local QDataStream to serialize the message,
>stuff the message in that, look how many bytes it is, then pull the
>message off as raw bytes and toss them on the actual TCP stream with the
>size in front.

That's a very common operation.

>> So readyRead() is emitted once there's data to be read. Unlike a
>> socket polling, if you don't read the data, you won't be reminded
>> again. The signal emits again only when more data arrives.
>
>Makes sense, since you aren't polling the Qt class :-). To make sure I
>understand, we're not talking about strict edge triggering though,
>right? Any time Qt is able to suck more data off the socket, you get a
>new readReady? (IOW, you get a readReady exactly when the number of
>available bytes increases?)

Any time new data is available for you to read, you get a readyRead().

In the case of QSslSocket, that's not directly tied to socket bytes. It 
may have to decrypt data or just handshake. Those bytes read from the 
socket but that don't produce readable data for you, don't trigger 
readyRead().

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]