[Interest] TCP ACK with QDataStream -- OR: disconnect race condition detection

Reinhardt Behm rb at rbehm.de
Mon Sep 10 20:59:11 CEST 2012

On Monday 10 September 2012 12:02:38 Till Oliver Knoll wrote:
> Am 09.09.2012 um 21:17 schrieb Justin Karneges <justin at affinix.com>:
> > You're correct in that it is reliable under the hood. The problem is
> > really just that most TCP APIs don't expose to the app what has been
> > acknowledged.
> Not entirely true: on a "socket level" you get the number of bytes which
> have been ACK'ed ("successfully read") by the counterparty's Transport
> (TCP) layer - that is, they are now stored in the counterparty's
> (receiver's) read buffer, ready to be picked up by the Application layer
> (whether the counterparty's Application layer will eventually do so we
> don't know!).
> Qt /does/ provide you with this info! That's what the signal
> QIODevice::bytesWritten is for.
> However note that when you e.g. sent 4097 bytes, but the signal reports
> "4096 bytes written (and ACK'ed by the receiver!" that does /not/ (yet)
> imply that one byte was lost! That one byte might just be sitting around
> in some OS / TCP/IP stack-specific buffer waiting to be filled up
> (keyword: "Nagle's algorithm") - and sent later.
> However I said "not entirely" because you might be correct that some APIs
> don't let you know how many bytes were ACK'ed by the counterparty. Qt is
> /not/ one of them. ;)
> Cheers,
>   Oliver
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

And since each packets might take a different route and thus will not arrive 
in the order they have been sent, the missing byte does not even have to be 
the byte # 4097.

Reinhardt Behm

More information about the Interest mailing list