In message <20050327214324.GA27358@panix.com>,
Thor Lancelot Simon writes:

>On Sun, Mar 27, 2005 at 01:34:45PM -0800, Jonathan Stone wrote:

>Matt Thomas pointed out that my supposition about using a low-water mark
>on the send socket buffer was also wrong: output UDP doesn't _use_ the
>socket buffer, 

I was wondering about that.

>and even if it did, since the destination address is
>per-packet, you couldn't just assume that "the" underlying ifq would
>drain, resulting in the socket buffer draining: there might be several
>underlying interface queues.

Yes. The namespaces are incommensuate, too: the namespace for send()
is protocol addresses, but the ifq is bound ot an interface, and
interfaces (as far as I can see) are usually named by interface name.

Small digression: somewhere, I have a hack that lets one bind netinet
sockets to a specific interface, thus allowing multiple interfaces on
a given subnet, whilst letting TCP applications "steer" their output
to a specific interface.  The idea is based on Eliot Poger's
SOBINDTODEV operation in Linux (which I also suggested to Eliot).
Instead of doing interface-binding at the socket layer, I did it at
the pcb (which seemed a better fit to our stack), and I leveraged the
existing multicast addressing ioctls --- which, ahah, *do* name the
desired interface by IP address.

... with regrettable consequences, if the interface addresses get
changed under you.


[...]

>Something conceptually like selectto() could fix this in a cleaner
>way than by letting send() block... but would be nonstandard as well.
>
>This really is a bit of a mess.

Yes. but if you ask an Internet old-timer, they'll tell you that UDP
was never *meant* to be reliable, and that UDP was merely a shim to
expose IP best-effort datagram service to user applications, with some
minimal headers for demuxing multiple apps (my summary, from memory,
of something Bob Braden said years ago on e2e).

And as you know, if you send too fast over IP, your packets get
dropped.  Endit.

So under certain circumstances, the drop happens between the UDP stack
and your interface send queue, rather than inside the network or at
the receier or at your next-hop router?
A <shrug> is all you'll get.

BTW, does ttcp -U still report send-side rates greater than the
interface data rate?  If it does, do we actually have any problem?
I don't think so.