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

[d3fault]

lol thanks for explaining to me what TCP is. Already knew that before
making this thread... just didn't know the transport ACKs weren't
accessible from application layer (especially after reading that
[fixed] misleading documentation).

But how can you say:
a) TCP ACKs can't be used for application layer reliability
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

and then follow it up with:
c) A generic application layer ACKing scheme doesn't have value


Sure, my design I literally made up while typing that email might have
flaws... but that's what designs are for!

Fixes: 2-stage ACKing. 'application-layer-read-it-in' ACK, and
'application-layer-processed-it' ACK. The latter would require the
user code to call some 'messageProcessed' function (an application
layer ack scheme would be message based, not stream based like TCP).
Also it would be good to allow the user to specify in the constructor
whether they want to have read-acking, processed-acking, or both
(neither wouldn't apply -- why use the class?).

ACK'ing the ACK is also a problem. You could ACK the ACK, but then you
have to ACK the ACK's ACK and where does it end :-P? A quick/easy fix
for that is to use QTcpSocket when telling the class which variant of
QAbstractSocket you want to use (edit: wait a minute, nvm. this has
the same problem... we don't know that the ACK's ACK made it to the
application layer fml). A proper solution requires more thought. It
probably wouldn't be too complicated. Famous last words?

Such a class could greatly simplify application protocol creation.

Weeeeeeeeeee http://xkcd.com/1081/

d3fault