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

[Till Oliver Knoll]

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

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

I was just thinking for a moment that "knowing the number of ACK'ed bytes" /could/ be useful in some cased, as in "implementing a minimal reliable message protocol" (based entirely on the "TCP reliability".

But off course on second thought, having that knowledge ("the amount of ACK'ed bytes on the Transport layer") would (should!) only *minimaly* raise your level of confidence in such a protocol (if at all!), for all the reasons mentioned.

Even for a simple task such as "Resuming an interrupted download" you *must* have a protocol on the Application layer: the amount of ACK'ed  bytes does tell you *nothing* how much the client actually stored on disk, and from where you *really* need to resume.


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

Exactly :)

By the way, this has all been discussed here, for instance:

  http://stackoverflow.com/questions/628149/tcp-getting-num-bytes-acked

With pretty much the same outcome as here ;)

Cheers,
  Oliver