On 2006-07-03, Ben Sizer <[EMAIL PROTECTED]> wrote:
> Grant Edwards wrote:
>> You're talking about the case where there's un-ACKed data.
>> Breaking a link when there's no un-ACKed data (which is what
>> the OP did) will require an hour or two to timeout _iff_
>> keepalive is enabled. If keepalive has not been enabled, a
>> broken connection with no un-ACKed data will never timeout.
>
> My mistake, Grant. I was under the impression that a blocking
> send() would wait for an ACK before proceeding, but upon
> checking the man pages I see that this is not the case.
It would be awfully nice if there was such an option. I've
needed to do exactly that once or twice, and had to add a
kernel-mode ioctl() call to the Linux kernel so I could wait
until the data sent on a socket had been ACKed. The reason I
needed to do that was because the application layer protocol
was broken with no way to change it.
> It does seem to make the oft-cited TCP guarantee of data
> arrival a little weaker however, if you can't necessarily know
> how many of your sends have succeeded or not. Doubtless I am
> missing something here, too. Time to dig out my old networking
> notes, perhaps.
If you really do need to know if the data got there, I guess
you're supposed to use an application layer ACK. Even if you
could wait for an ACK, that only means that the TCP/IP stack on
the other end got the packet. It doesn't mean that the
application has read the data (the application could well be
locked up somehow with the data that has been ACKed just
sitting in a buffer).
--
Grant Edwards grante Yow! Now that we're
at in LOVE, you can BUY
visi.com this GOLDFISH for a 48%
DISCOUNT.
--
http://mail.python.org/mailman/listinfo/python-list
