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

[Thiago Macieira]

On segunda-feira, 10 de setembro de 2012 13.33.24, Till Oliver Knoll wrote:
> 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".

If TCP is reliable by doing ACKs, why the hell would you need to track ACKs 
too? It's redundant: if you get the ACK information, that's because TCP got it 
too; if you don't get it, neither did TCP. Therefore, TCP has already got all 
the information it needs in order to be reliable.

You can't add more reliability with the same information.

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

Exactly.

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