2012/9/11 d3fault <d3faultdot...@gmail.com>:
> lol thanks for explaining to me what TCP is. Already knew that before
> making this thread...
There still seem to be some mis-conceptions about what TCP *really* is
(and "network layers" in general) on your side though ;)
Let's go through it step by step (I'm no network expert either, so I
probably make over-simplistic statements, but you'll get the point
anyway, I hope):
By the way, did you already read my previous post?
> But how can you say:
> a) TCP ACKs can't be used for application layer reliability
Because a "TCP ACK" simply means: "I have received the first N bytes
in *order*". Point. There is no more information in that, other than
the sender knows: "Yes, the *Transport* layer (repeat after me:
*Transport* layer, *Transport* layer...) has properly received the
first N bytes in order.
That simple.
Or in other words: the Transport layer has no clue - and most
importantly: *should* not have any clue! - what the *above* layers
(plural) would do with those N bytes! For what it's word they could be
parsed, split, stored to disk or compressed as MP3 and sold for Big
Money on the market - we simply don't know!
The *Transport* layer has no clue about the *content* of the stream:
its sole purpose is to "transport" (sic!) them from A to B. Reliably.
In order.
That's what the "Transport ACK" is for (and it happens to be the
number of bytes received in case of the TCP implementation - but could
be something completely different, specific to that Transport layer
implementation).
So we should have a common understanding up to this point - and we
keep repeating this over and over again, as you notice ;) - that the
"Transport ACK" has *only* a meaning ... for the Transport layer! And
that meaning usually does not go much beyond "N bytes received in
order" (depending on the actual Transport layer).
Clear so far? If not, re-read my previous words.
> b) Everyone that wants to have application layer reliability has to
> implement their own ACK scheme... reinventing the wheel of not only
> the TCP ACK, but also each other
That's where your mis-conception is probably based upon! When we talk
about "Application level protocol", there is MUCH MUCH MUCH more
involved that just "I have received the first N bytes in order"!
Remember the HTTP example I gave you, "404 Not found"? That is a very
simple example, but it perfectly illustrates the point: you have a) an
error code (404) and a "human readable string" ("Not found"). Plus
lots more of meta information: size of the entire message, MIME-Type,
other error/success/redirect codes...
Yes, we're talking about HTTP, which is based *on top* of (usually)
TCP. And HTTP is an "Application level protocol"! TCP doesn't
understand nada about HTTP, and on the other hand the information that
the counterparty (server or browser) has received "the first N bytes -
in order" is worth... nothing! You really need more information:
status codes, URLs for further resources to request etc. etc.
So by now we should have a common understanding that a) "Application
level protocol" is usually (in almost all cases) much much much richer
in information than "Transport level protocol" and b) the information
from the underlying layer should NOT be used for your higher-level
protocol!
For example, imagine HTTP relying on the "number of bytes received in
order" - that would mean that HTTP could *only* be used over TCP -
and not over e.g. UDP or any other Transport protocol.
On the other hand HTTP gains *nothing* from knowing that the
counterparty's Transport layer has received "N bytes in order"! It
*already* knows that (by the fact that TCP is reliable) and they have
or will eventually reach the counterparty - or we will get an error
code telling us otherwise. So knowing "how many bytes" doesn't give us
useful extra information (except maybe in that progress bar example -
but we'll quickly forget about that one, shall we ;))
We really need those HTTP status codes etc. - and those are...
Application *specific*! (So *no*, QAbstractSocket wouldn't know (and
*must not* know) nothing about those HTTP specifica and couldn't
generate them for us - they are *specific* to our application: Web
Browsers and Servers in our case).
Clear so far? If not, re-read my previous words. ;)
>
> and then follow it up with:
> c) A generic application layer ACKing scheme doesn't have value
So from the above two points directly follows that yes, "A generic
application layer ACKing scheme doesn't have value".
If that is not clear to you yet, re-read point a) and b)
> ...
> ACK'ing the ACK is also a problem.
Fortunately that is already solved for us - by the Transport layer (TCP) ;)
And we did not even go into all the problems like delays, extra
overhead, how Qt should "intermangle" those status updates into the
actual payload stream etc. etc. such a simple and generic "ACK
protocol" would have, implemented on the *Application* layer.
If you're really curious about all this, then get a good book:
"Computer Networks" by Andrew S. Tanenbaum (a classic and must-read!)
was already mentioned.
I hope that clarifies things a bit :)
Cheers,
Oliver
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
