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

[d3fault]

3rd time down the waterslide... this is so fun ^_^

On Tue, Sep 11, 2012 at 1:58 AM, Till Oliver Knoll
<till.oliver.knoll at gmail.com> wrote:
> I understood very well that you're talking about a "generic
> Application layer ACK" concept/protocol (implemented in e.g.
> QAbstractSocket or in some other Qt related class).
>

No you don't, as you demonstrate in the next few paragraphs.

> What I'm trying to get over is that auch a generic "ACK protocol"
> doesn't provide any useful information to a concrete application,
> because you would gain nothing more than "the bytes have been received
> by the other side".
>

If you remember why I started this thread, that's EXACTLY the
information I want.

> The *only* difference in your case is that this information is now
> conveyed in the Application layer instead of the Transport layer, but
> the information per se, "N bytes received in order", is *exactly the
> same*!
>
> Well, there is another difference: in the context of the Transport
> layer this information is useful - and crucial, if we want to be
> reliable - whereas in the context of the Application layer it is
> useless!
>
>
> Why? Ok, let's assume you would use UDP and your "Qt Application Level
> ACK Protocol". My application sends to your server some "message" of
> say 1000 bytes.
>
> At some point my QAbstractSocket emits a signal telling me "The
> counterparty QAbstractSocket has detected that the underlying network
> layer has now 750 bytes (really any number) of bytes ready for the
> Application to read".
>

See this is where you're confusing the TCP ACK with the Generic
Application Layer ACK. I would be emitting the first ACK not when the
buffer is filled (which is when the TCP ACK is sent)... but instead
when the application layer (user code) has read it in. AFTER the user
code has read it in. Then (optionally, additionally) another ACK for
when the data's been processed...

> Okay, so what do I know? I know that the other application *could*
> read those 750 bytes - *if* it decides to read it or more severily: if
> it is *able* to do so. And the later is *impossible* for Qt (the "Qt
> Application Level ACK Protocol") to know! Impossible!
>
> So again, what do we know? Yes, nothing more that the other
> application *could* read 750 bytes (or already did - who knows!).
>
> Let's continue a little bit. So some times later my QAbstractSocket
> emits another signal telling me "The counterparty QAbstractSocket as
> detected that the underlying network layer has now 1000 bytes ready
> for the Application to read".
>
> Well then, I finally know that my 1000 bytes went over the wire.
> *Nothing more*! Again, Qt could detect nothing more than what TCP
> already does! Qt cannot know what and if the application is going to
> do with those 1000 bytes.
>
> And that's the end of the story.
>
> So what did we gain? Nothing: We already know that when using TCP
> (only) that those 1000 bytes will be sent to our Counterparty - or not
> (in which case we get reliably an error message like "connection
> broken"). The fact that in your scenario it is the "Qt Application
> Level ACK Protocol" which would tell us the *same* thing doesn't add
> any value! Not a single bit of extra information!
>

Similar information, used at different level in OSI Model... and as
has been mentioned many times before: custom application layer
protocols have to do this anyways (well, if they want application
layer reliability).

>
> So how would Qt distinguish between ACK sent by the other
> QAbstractSocket and actual payload?
>
> That is just one problem (which off course could be solved), the
> others such as delay (Nagle's algorithm!) and dozens of others - all
> of which are already solved for us in the underlying Transport layer -
> I already hinted at.
>

The class does this transparently. Not difficult at all.

>
> There is no possible way Qt could
> provide us with a "generic ACK protocol" which would be useful for any
> application. Just go back to the simple HTTP example (and yes, HTTP is
> a protocol in the Application layer).
>

>no possible way
That's quite a statement.

And when did I say HTTP wasn't on the application layer?


A [poor] analog to what I'm describing is QDataStream itself: It wraps
a QIODevice and inserts encoding data on the sender side and strips it
for you on the receiver side... but it's still in the application
layer.

The Generic ACK'er would become part of the application protocol...
and (just like QDataStream) would be intended for Qt <--> Qt
communication.

d3fault