2012/9/11 d3fault <d3faultdot...@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.kn...@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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
