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

[Justin Karneges]

You're correct in that it is reliable under the hood. The problem is really 
just that most TCP APIs don't expose to the app what has been acknowledged. It 
is pretty sad that everyone solves this by layering acks on top, when acks are 
already being performed a layer down.

I think it would be neat if QAbstractSocket had another signal, like 
bytesAcknowledged(), that worked by using platform-specific methods to figure 
out what has been definitely sent. Again, though, there are major 
interoperability concerns with this. Think not only about operating systems 
but also frameworks and languages. For example, if you made a protocol that 
dependend on this ability, would you be able to interop with a C# peer? Maybe, 
maybe not. I suppose if it is just Qt<->Qt (given that you are using 
QDataStream), then maybe this doesn't matter.

On Sunday, September 09, 2012 11:54:09 AM d3fault wrote:
> Haha, funny. Reliable doesn't mean reliable. Who knew...
> 
> Are you sure it isn't just Qt failing to utilize the TCP protocol
> correctly? I don't mean to question your expertise, as you sound like
> you know what you're talking about, but this quote from wikipedia
> makes it sound like TCP does in fact do mid-stream reliability: "TCP
> primarily uses a cumulative acknowledgment scheme, where the receiver
> sends an acknowledgment signifying that the receiver has received all
> data preceding the acknowledged sequence number" [0]. That plus
> automatic re-transmission of lost packets sounds like exactly what I
> want! How do I get that number in a platform independent manner [and
> make sense of it]?
> 
> 
> I was going to code my own ack layer on top of TCP... but after a few
> designs and reading further into TCP it sounded an awful lot like
> reinventing the wheel. I came up with my own sequence number scheme
> and everything and oh boy TCP really sucks if you're right :-P...
> 
> 
> 
> An actually-reliable-tcp-socket class (called something else, and
> perhaps based on QAbstractSocket instead?) sounds like it would make a
> great addition to Qt don't you think? Maybe something along the lines
> of QNetworkRequest::Acknowledged() [signal].... though not necessarily
> anything to do with QNAM (especially since the QNetworkReply makes a
> better acknowledgement in that case lol (and now I'm just confusing
> myself)).
> 
> 
> [0] -
> http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Reliable_transmi
> ssion
> 
> 
> d3fault
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest