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

[Till Oliver Knoll]

Am 11.09.2012 um 06:40 schrieb d3fault <d3faultdotxbe at gmail.com>:

>> From this thread I've learned: It's useless for an application layer
> to receive transport layer acks... but from that we can now conclude
> that the transport ack is mostly* worthless ...
> 
> * = clean connect/disconnect + packet re-ordering aside -- see below

You don't quite understand how important packet (packet! Not message!) re-ordering is: TCP doesn't know about "messages", message sizes... from it's point of view it just transport an opaque stream of bytes: in ORDER and WITHOUT HOLES - or you'll be informed that something went wrong!

One could say this extra-overhead to accomplish this is actually the whole point of TCP!

You don't need that? Your app can (wants to) deal with "HelWor lod" instead of "Hello World"? You don't care if parts of messages go missing (unnoticed by the Transport layer)?Use something else (UDP) :)

Grab any good book about networking and understand why it is not (always) that trivial to send data over an unteliable medium such as an old rusty telephone cable! ;)



> 
> Thiago, you said getting the TCP ack is redundant...

He did not say that.

> but the TCP ack
> itself is redundant if you have an application layer protocol taking
> care of ack'ing too.

The meanings of those ACK would have different semantics - besides, only in the simplest case would you send a simple "ACK" (boolean). Go and see what even a simple web server sends you (status codes, messages ... ever seen "404 Not Found" in a web browser? ;))


> 
> So the only thing really gained from TCP [when using app-layer ack'ing
> scheme] is the clean connects/disconnects and packet ordering.

That "only" thing is not to be underestimated. ;)


> The
> connect/disconnect ability is easily solved with 2 new protocol
> messages, and the ordering being an important guarantee is specific to
> the application itself.

No, it's not specific: there is just ONE ordering: the CORRECT one. That's not specific to any application.

The alternative is you order the bunch of bytes yourself.


> Some might require it, some not.

Correct. That's what UDP is for.

> 
> I think a generic application layer ack'ing scheme/class based on
> QAbstractSocket would be a great addition to Qt.

No, it would not. It would simply duplicate what TCP does already. And when should Qt send an "ACK"? It doesn't (cannot!) know when the actual application logic has dealt with the "message"!


> So when you receive
> an ACK you are guaranteed that your receiver's application layer has
> read it in (acting upon it is something else entirely).

But that acting upon is the important part here! Anything else doesn't add much gain: for instance the app might crash before it can persist the data, but Qt has already "ACK" the message - just exactly as TCP did (or would do, if you would still use TCP).

So you gained ... nothing. Except that the ACK now came from the Application layer (wasting more bandwith than the ACK of the Transport layer, is NOT guaranteed to reach the sender either, because you just said you don't need the reliability of TCP, might get delayed, because a few bytes of the Application layer are not send until a) the send buffer is large enough or b) only after some timeout -> additional delays etc. etc. etc.



> It could also
> (optionally, to be disabled when used with TCP -- or if your specific
> use case doesn't require it) do message re-ordering for you.

So re-implement TCP, in case you don't want TCP. But with more overhead abd delay. Hmmmm ;)

Cheers,
  Oliver