sockets: How to know when your data is sent
mederis at hotmail.com
Wed Nov 10 15:44:07 CET 2004
Grant Edwards <grante at visi.com> wrote in message news:<4190fdab$0$87168$a1866201 at visi.com>...
> On 2004-11-09, Sion Arrowsmith <siona at chiark.greenend.org.uk> wrote:
> >>> When I use the send function, it will happily send a buffer of
> >>> a megabyte and more in one shot. But of course, the data is
> >>> still in the network buffer... [ ... ] The problem is, how
> >>> can I know when it's done?
> >>Under Linux, there is no way to tell. IIRC, there's no way to
> >>tell under BSD either. I actually wrote some kernel mode code
> >>once upon a time to provide an ioctl() that I could call from
> >>user space to find out when the data I had written to a socket
> >>was actually sent.
> > I may well be missing the point of the problem here, but wouldn't
> > just turning TCP_NODELAY on guarantee that send() won't return
> > until the last ACK has returned?
> Nope. Send returns as soon as the the data is copied to a a
> kernel-space buffer. TCP_NODELAY has no effect on that. It
> only changes the stack's behavior as it's taking data from that
> buffer and putting it on the wire. Eventually, the TCP window
> will fill up, and after than the tx buffer will fill up, and
> after that, send will block. There's no practical way to
> predict the size of either the TCP window or the tx buffer.
> There's also no practical way to determine how much data is
> still waiting to be acked (unless you want to do kernel
> > And if you're not using TCP:
> >>The way to tell that data has been sent is to use an
> >>application-level protocol that acknowleges the data transferr.
> > applies in spades if you care about reliability.
> Unfortunately, many people who write network applications (and
> protocols) make all sorts of bizarre assumptions, and somebody
> ends up jumping through hoops later to try to fix things when
> those assumptions turn out to be wrong. :/
I see, so the right way to do it is to have the server respond on a
successful receipt of the data. Thanks Grant. And thanks for
mentioning TCP_NODELAY, Sion, because I was about to try that too, but
this saves me the trouble.
More information about the Python-list