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

Till Oliver Knoll till.oliver.knoll at gmail.com
Mon Sep 10 12:54:50 CEST 2012

Am 10.09.2012 um 12:19 schrieb Thiago Macieira <thiago.macieira at intel.com>:

> On segunda-feira, 10 de setembro de 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.
> No, it's not.
> bytesWritten is emitted whenever QAbstractSocket has written to the socket 
> layer. That does not mean that they have been sent to the remote side, much 
> less that the other side has ACK'ed them.

Then it is about time that the Qt docs be corrected:

"The bytesWritten() signal is emitted when data has been written to the socket (i.e., when the client has read the data)."

With emphasis on "the client has read the data" that implies to me that the client has ACK'ed (on the Transport / TCP layer) the data.


> There's simply no way to get the number of bytes ACK'ed from the other side. I 
> did search the Linux TCP API yesterday and I couldn't find anything suitable. 

That comes as a surprise.

> And even if there were such a way, the ACK information is useless, since the 
> application on the other side may never read from the socket.

That's what I said. See my other notes about "At least/most/exactly once" semantics.

However I dare to say that for most "desktop networking applications" it is "good enough" to know the number of bytes vacing been ACK'ed by the client's Transport layer - if they care at all.

So no, I don't quite agree that this information is "entirely useless" (however I agree that if you're serious about e.g. "reliable message delivery" you'd want to combine that information with an Application layer protocol of some sort).

>> .... Qt is
>> /not/ one of them. ;)
> It is.

Not according to the documentation ;)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120910/d116b3a4/attachment.html>

More information about the Interest mailing list