sockets: How to know when your data is sent

[Grant Edwards]

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
hacking).

> 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. :/

-- 
Grant Edwards                   grante             Yow!  I wonder if I should
                                  at               put myself in ESCROW!!
                               visi.com