--===============1277990644==
Content-Type: multipart/signed;
  boundary="nextPart2185900.xN1hddDnZR";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2185900.xN1hddDnZR
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=20
buffer until you have a complete message. But, with peeking, Qt does the=20
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=20
may have to decrypt data or just handshake. Those bytes read from the=20
socket but that don't produce readable data for you, don't trigger=20
readyRead().

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

--nextPart2185900.xN1hddDnZR
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQBI09ZKM/XwBW70U1gRAsKCAJ9vnhK1RSu6/d5rtKApkFsgfdwzcgCaAmp2
Sd5PKDNT5NivEgqvrAuE4aU=
=KXCK
-----END PGP SIGNATURE-----

--nextPart2185900.xN1hddDnZR--

--===============1277990644==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1277990644==--