<p>When should that "application-level ACK" be sent?</p>
<p>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).</p>

<p>When the application reads the data? Then how can QAbstractSocket know when *exactly* to send the ACK?<br>
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?<br>
Neither TCP nor Qt socket classes [want to] know anything about the structure of the data transmitted over the network.<br>
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.).</p>

<p>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.</p>

<p>And finally, this discussion has already taken much more time than you'd spend adding these ACKs to your application. :-)</p>
<div class="gmail_quote">On Sep 11, 2012 4:22 PM, "d3fault" <<a href="mailto:d3faultdotxbe@gmail.com">d3faultdotxbe@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You haven't given any concrete reasons why I'm wrong, so I'll just<br>
assume you are until you prove otherwise (WHEEEEEEEEEEE). Repeating<br>
yourself doesn't count.<br>
<br>
Not every application protocol could use it... but a lot could.<br>
<br>
Also, responses and error codes are something else entirely. That<br>
would be in a reply which would go through the Generic ACK'er again<br>
back to the requester (the sender ACKs the receiver's reply). I'm only<br>
talking about ACK'ing. The information learned/gained is that the<br>
sender now KNOWS the receiver got it and/or processed it (as opposed<br>
to knowing it's sitting in the receiver's transport layer... worthless<br>
information to the sender's application layer). Can now stop the<br>
re-transmit timeout or whatever.<br>
<br>
You're right about one thing: this argument is futile.<br>
<br>
d3fault<br>
_______________________________________________<br>
Interest mailing list<br>
<a href="mailto:Interest@qt-project.org">Interest@qt-project.org</a><br>
<a href="http://lists.qt-project.org/mailman/listinfo/interest" target="_blank">http://lists.qt-project.org/mailman/listinfo/interest</a><br>
</blockquote></div>