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

[d3fault]

>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 in any case where the
application layer protocol takes care of ack'ing. Might as well use
UDP.

* = clean connect/disconnect + packet re-ordering aside -- see below

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

So the only thing really gained from TCP [when using app-layer ack'ing
scheme] is the clean connects/disconnects and packet ordering. 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. Some might require it, some not.

I think a generic application layer ack'ing scheme/class based on
QAbstractSocket would be a great addition to Qt. 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). 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. The class
would also take care of re-transmitting, of course (enabled by default
(even when ordering doesn't matter), disable-able for voip/streaming
video scenarios (you might think in this case it'd be better to just
use UDP... but knowing that the receiver got most of the messages is
still valuable information... whereas with UDP you just cross your
fingers and assume they did)).

^^I'll try to keep this in mind as I implement my application layer
ack'ing scheme... but obviously my own specific use case takes
priority sorry :-P.

To end, are there any plans to make QSslSocket work with QUdpSocket?
The overheads of TCP are redundant.

d3fault

inb4 a handful of people miss the point and try to explain to me why
tcp ack's are not redundant. "you're guaranteed ordering" hurrrrr