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

[Constantin Makshin]

When should that "application-level ACK" be sent?

When QAbstractSocket sees theres's some data available? That doesn't make
[much] sense IMHO -- nothing stops the application from throwing that data
away without any processing (due to crash or any other reason).

When the application reads the data? Then how can QAbstractSocket know when
*exactly* to send the ACK?
Let's imagine the sender sent 1000 bytes. Should the ACK be sent when the
receiving application reads these 1000 bytes? What if new data arrives
before that happens?
Neither TCP nor Qt socket classes [want to] know anything about the
structure of the data transmitted over the network.
On the other hand, applications usually exchange with some kind of
structured messages (old HTTP-like "end of message is marked by
disconnection" technique is obviously not the best solution due to overhead
caused by frequent reconnections). In this situation "message recieved"
ACKs are much more useful, but there's no universal way to do them because
different applications may need different data to be sent in the ACK
(message number, transaction ID, etc.).

Also you still haven't given any ideas how sender's Qt should solve the
problem of distinguishing these ACKs from regular application data.
Wrapping all data in QDataStream-like manner would both produce an overhead
not needed by most applications and make Qt-to-non-Qt connections
problematic.

And finally, this discussion has already taken much more time than you'd
spend adding these ACKs to your application. :-)
On Sep 11, 2012 4:22 PM, "d3fault" <d3faultdotxbe at gmail.com> wrote:

> You haven't given any concrete reasons why I'm wrong, so I'll just
> assume you are until you prove otherwise (WHEEEEEEEEEEE). Repeating
> yourself doesn't count.
>
> Not every application protocol could use it... but a lot could.
>
> Also, responses and error codes are something else entirely. That
> would be in a reply which would go through the Generic ACK'er again
> back to the requester (the sender ACKs the receiver's reply). I'm only
> talking about ACK'ing. The information learned/gained is that the
> sender now KNOWS the receiver got it and/or processed it (as opposed
> to knowing it's sitting in the receiver's transport layer... worthless
> information to the sender's application layer). Can now stop the
> re-transmit timeout or whatever.
>
> You're right about one thing: this argument is futile.
>
> d3fault
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120911/43b3a02f/attachment.html>