Re: ping: sendto: No buffer space available

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Mon, Oct 10, 2011 at 10:39:03AM -0700, Erik E. Fair wrote:
>
> How do your applications now handle ENOBUF?

Generally, they're managing many, many datagram conversations at
once.  Typically, they'll handle ENOBUF by setting a timer to retry
the context that elicited the list "later" -- generally meaning at
the next step in whatever backoff mechanism they use to deal with
non-responding peers in general.

ENOBUF, then, is a pain, because it has to be special cased within
the error handling path (other errors typically lead to an immediate
retransmission of the datagram), but in terms of behavior, it's basically
like any other indication of packet loss, including timeout.  And
that leads me to the conclusion that the explicit indication of
error makes the application code more complex but is otherwise
without value.

More details than that, about the code like this I've written lately,
I'm afraid I can't give.  Another interesting perspective would likely
come from someone who's worked on a UDP media streaming application,
which isn't something I've done -- though I've debugged one, which
turned out to stupidly assume it would get some kind of explicit error
notification on any packet drop, and to be basically unable to detect
that it was flooding the network and downshift its data rate accordingly.
If you think about it, NFS over UDP kind of has this problem, and it's
one reason why people sometimes used to intentionally set switch ports
in mixed-speed networks to half-duplex (before there was standardized
flow control for full-duplex gigabit links) so the switch had some way
to "notify" the sender it was overrunning its peers.  Eventually the
sending host would run out of buffers and slow the hell down.  Eventually.
But that is not a good way to achieve the goal.