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

[Till Oliver Knoll]

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