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

[d3fault]

On Sep 10, 2012 4:37 AM, "Thiago Macieira" <thiago.macieira at intel.com>
wrote:
>
> 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.
>

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

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

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