[Interest] TCP ACK with QDataStream -- OR: disconnect race condition detection
d3faultdotxbe at gmail.com
Mon Sep 10 13:58:55 CEST 2012
On Sep 10, 2012 4:37 AM, "Thiago Macieira" <thiago.macieira at intel.com>
> On segunda-feira, 10 de setembro de 2012 13.33.24, 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
> > > Transport layer works. As I pointed out, the Transport layer may
> > > 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
> > /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
> too? It's redundant: if you get the ACK information, that's because TCP
> too; if you don't get it, neither did TCP. Therefore, TCP has already got
> the information it needs in order to be reliable.
> You can't add more reliability with the same information.
You can't add more reliability, true... but you could [hypothetically]
utilize that lower level information in building some sort of pseudo
application layer ACK scheme. Knowing that your data made it to the
receiver's Transport layer is good enough if you are ok with relying on
"statistical faith" that the application layer will read it -- and this of
course ignores the many ways you mentioned the message could get stuck in
I don't think anyone's proposing doing that... as it would break in a lot
of cases.... but it's still 'possible'....
This discussion isn't going anywhere anymore, but I sure learned a lot :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest