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

[Till Oliver Knoll]

2012/9/11 d3fault <d3faultdotxbe at gmail.com>:
> 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.

So you're *not* talking about a "generic Application layer ACK"
concept or protocol (implemented in e.g. QAbstractSocket or in some
other Qt related class) - as you continue to do so in your next few
paragraphs? ;)

Well then, my wrong ;)

>> What I'm trying to get over is that auch a generic "ACK protocol"
>> doesn't provide any useful information to a concrete application,
>
> If you remember why I started this thread, that's EXACTLY the
> information I want.

Fine. Go ahead and implement that in your protocol *specific to your
very own application* - and to that alone. No one tells or did tell
you you could not do that.

However I keep repeating myself when I tell you that this information
alone *won't* increase your knowledge on the other side (sender's
side).

>> The *only* difference in your case is that this information is now
>> conveyed in the Application layer instead of the Transport layer, >
>> ...
> 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.

Yeah, whenever. The information is the same. And besides: The fact
that the application has actually *read* the buffer *still* does not
add *any* level of confidence or adds any information you would
already have by using TCP alone.

Well, agreed, now the sender knows a little tiny detail more: "The
receiver has read the buffer".

So what?! What do you gain from that? Exactly: nothing! You still
don't know whether the receiver has actually *processed* the data
successfully!

Off course now comes your Deus Ex Machina...

>  AFTER the user
> code has read it in. Then (optionally, additionally) another ACK for
> when the data's been processed...

... and all of a sudden another generic API appears, the "I have
processed the data". But how? What would be the return value? An
integer? 0 = success, 1 = error, 2 =
AskMeWhateverYouWantMeToAskButI'llKeepIgnoringYou? Or a user-provided
data structure?

And all of a sudden we are in the application *specific* protocol land
again, and Qt couldn't possibly foresee all possible use cases! Even
the simple ones.

Oh and I did not even touch the topic of "lost ACKs", because the
whole point of your "application level ACK" protocol seems to get rid
of TCP. So your generic ACK mechanism would have to deal with lost
ACKs.

Not to mention all the overhead.


>> ...
>> So what did we gain? Nothing: We already know that when using TCP
>> (only) that those 1000 bytes will be sent to our Counterparty ...
>> 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...

Except that on one level - the Transport level - they make sense,
whereas in the other level knowing the number of bytes *received* (but
not necessarily *processed*) is usually worthless information.

> and as
> has been mentioned many times before: custom application layer
> protocols have to do this anyways (well, if they want application
> layer reliability).

No, no, no and no! You still did not understand the concepts of
"reliability"! You do *not* add any information about reliability by
adding the "number of bytes received" to the Application level!

What you want to know is whether the counterparty could *process* -
emphasis on *process* - the data. The fact that it was already
reliably *transported* YOU ALREADY KNOW - by the fact alone that
you're using TCP!

So how do you achieve "reliability" on the *Application level*? NOT by
*duplicating* the functionality of the underlying Transport layer -
and that's exactly what you propose to do! Plus your Deus-Ex-Machina
API "message processed".

So YES: you CAN implement that in YOUR protocol - it might be
ABSOLUTELY SUFFICIENT to know SPECIFICALLY in YOUR application that a)
N bytes have been read and b) the counterparty has "processed" (in
whatever way). But again and again: the  result, error codes and
further actions to take (on BOTH sides possibly) are all APPLICATION
SPECIFIC - heck, that's why it is called APPLICATION layer after all.

So it is absolutely futile to think such a "Generic application layer
based ACK protocol" (and you ARE talking about this topic, now aren't
you? Just triple-checking...) could be part of any Qt API! Because for
all the other 99.99% of applications out there YOUR protocol would be
absolutely useless - for all the reasons mentioned so far.


So, and now I ran out of ideas to emphasise my words - I used all caps
and bold asterisks there are ;).

>> So how would Qt distinguish between ACK sent by the other
>> QAbstractSocket and actual payload?
>>
>> ...
>
> The class does this transparently. Not difficult at all.

It doesn't matter of difficult or not it is: It is not worth thinking
about, for all the reaons (delay, overhead, duplication of
functionality on the wrong layer...) mentioned.


>
>>
>> There is no possible way Qt could
>> provide us with a "generic ACK protocol" which would be useful for any
>> application.  ...no possible way
> That's quite a statement.

I can repeat it for you: "There is no possible way Qt could provide us
with a "generic ACK protocol" which would be useful for any
application"

Well, "any" as in "it might be useful for some specific applications
(and I dare to say: probably only YOUR application ;)), but not in a
general sense - hence not worth including it in the Qt APIs".

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

I don't know - did you? I did not make such a statement - ever ;)

I was just giving HTTP as a random example of an "Application layer
protocol" in my apparently futile attempt to show you that even a
*simple* application protocol quickly outgrows your simple "message
received" generic approach. And that in "real world application"
"reliability" is dealt with on an entirely different level than your
simple "ACK and message processed" idea ;)

Cheers, Oliver