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

[Thiago Macieira]

On segunda-feira, 10 de setembro de 2012 12.54.50, Till Oliver Knoll wrote:
> 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.
> 
> http://qt-project.org/doc/qt-4.8/qabstractsocket.html

Thanks for pointing it out. Correcting:

https://codereview.qt-project.org/34513

> > 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.

It's not, if you read this part:

> > 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).

It's a layering violation for the Application layer to depend on how the 
Transport layer works. As I pointed out, the Transport layer may deliver the 
bytes and even ACK them, but the Application layer above may never receive 
them, for a variety of reasons.

For example, the application may exit unexpectedly before reading those bytes. 
It may fail to decrypt them (Presentation layer). It may decrypt them and fail 
to parse them. And even if the socket correctly delivers the bytes and they 
are interpreted correctly, the application may fail to act on them (e.g., 
delayed action).

For all those reasons and many others, the information is useless. Why does 
the local-side application care that the bytes were received? Since the layers 
above Transport can still fail, the information is useless.

It cares that the bytes were correctly interpreted and that the requested 
action was taken. That requires an Application-layer acknowledgement.

> >> .... Qt is
> >> /not/ one of them. ;)
> > 
> > It is.
> 
> Not according to the documentation ;)

Not for long.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden