sockets: How to know when your data is sent

[Marc Ederis]

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


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.

-Marc