On Monday 10 September 2012 12:02:38 Till Oliver Knoll wrote:
> Am 09.09.2012 um 21:17 schrieb Justin Karneges <jus...@affinix.com>:
> > 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.
>
> Not entirely true: on a "socket level" you get the number of bytes which
> have been ACK'ed ("successfully read") by the counterparty's Transport
> (TCP) layer - that is, they are now stored in the counterparty's
> (receiver's) read buffer, ready to be picked up by the Application layer
> (whether the counterparty's Application layer will eventually do so we
> don't know!).
>
> Qt /does/ provide you with this info! That's what the signal
> QIODevice::bytesWritten is for.
>
> However note that when you e.g. sent 4097 bytes, but the signal reports
> "4096 bytes written (and ACK'ed by the receiver!" that does /not/ (yet)
> imply that one byte was lost! That one byte might just be sitting around
> in some OS / TCP/IP stack-specific buffer waiting to be filled up
> (keyword: "Nagle's algorithm") - and sent later.
>
>
> However I said "not entirely" because you might be correct that some APIs
> don't let you know how many bytes were ACK'ed by the counterparty. Qt is
> /not/ one of them. ;)
>
> Cheers,
> Oliver
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
And since each packets might take a different route and thus will not arrive
in the order they have been sent, the missing byte does not even have to be
the byte # 4097.
--
Regards,
Reinhardt Behm
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
