From: Rob L. <ro...@la...> - 2005-03-11 03:19:59
|
On Tuesday 08 March 2005 12:46 pm, Nuutti Kotivuori wrote: > With UDP, the userland program has no way to throttle itself or know > how fast the network can send UDP packets. In there, saying sendto for > the UDP packets, might return ENOBUFS, but from the manpage of > sendto(): > > ENOBUFS > The output queue for a network interface was full. This gener- > ally indicates that the interface has stopped sending, but may > be caused by transient congestion. (Normally, this does not > occur in Linux. Packets are just silently dropped when a device > queue overflows.) > > So, UDP send performance measures with packet drop are not really > meaningful, since it all depends on how much time the userland process > gets time and if that is more than what the network device can dish out. > > -- Naked The logical thing to return for a temporary nonblocking congestion condition is -EAGAIN to indicate the packet was dropped, but retransmitting it should work. (Client programs are free to ignore this, and if broken clients didn't ignore it and it screwed up existing implementations, possibly an extra open flag would be necessary to trigger it.) Putting this in UML itself wouldn't help, but if the host kernel did this UML (and TCP in general) could throttle more sanely. However, nobody's ever bothered to fix this because UDP is not a guaranteed protocol over the internet or hub-based ethernet. Now that we've got switched ethernet (synchronous in the case of gigabit), packets are virtually never dropped over a LAN and it's possible that some infrastructure to not drop packets without remarking on it in the kernel's own packet handling layers is now worth the bother... But I'm unlikely to personally code it up any time soon. :) Rob |