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

[Till Oliver Knoll]

2012/9/11 d3fault <d3faultdotxbe at gmail.com>:
> Our thoughts seem to have diverged a few emails back. I'm no longer
> talking about TCP/Transport layer when mentioning ACKs... just the
> concept of acknowledgment. Screw it, I'm just going to go down my
> water slide repeatedly.

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

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

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

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!


> Also, what does intermangle mean? Seems to be a made up word and I
> can't figure it out from the context. You mean message re-ordering?

Sorry, I must confess I made up that word - it was lingering in the
back of my head (I'm not a native english speaker - however "mangle"
does exists, and also somewhat describes what I meant ;)

What I meant is - assume Qt would to that "Generic ACK protocol" for
us - that Qt would have to "inject" ("mix in") those "status messages"
into the same socket stream as our own payload. Because we are on the
*same* Application layer!

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.


I guess the most important point here is to understand that a protocol
in the Application layer is - as the name "Application layer" actually
implies - application *specific*. 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).

Cheers, Oliver