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

[André Somers]

Op 11-9-2012 14:22, d3fault schreef:
> 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.
It seems to me you have it all figured out, and don't need further 
advice. Fine. So go ahead and build it! I for one am curious what you 
come up with.

I think that in principle, it could be useful to have a generic 
message-based set of networking components that operate on top of TCP. 
Perhaps you could model it after the QNetworkAccessManager with the 
QNetworkRequest and QNetworkReply classes. I don't know what you have in 
mind exactly, of course, but you'd either need to provide a server-side 
component or design it in a way that the classes operate peer-to-peer.

André