Luigi Rizzo wrote:
>
> > Hi,
> >
> > I'm wondering if anyone has ever considered modifying the UDP behavior with
> > regard to selecting:
> >
> > Currently, writing to a UDP socket either enqueues packets in the interface
> > queue (returning success), or drops them on the floor (returning ENOBUFS)
> > if the queue is full. Selecting-to-write on a UDP socket always succeeds,
> > never blocks.
>
> I think it would require some substantial change to the network
> stack structure (basically to let your sockets sleep on an interface,
> and being woken up when the queue drains).
Exactly.
> There are fairness and efficiency issues here, because the device
> queue has so many "users" that the usual low-water/high-water
> strategy might cause a blocked socket to starve forever, so you
> might need to effectively block queueing if there are sockets
> sleeping on a queue, maybe issue a wakeup() on every single
> transmission when you have sockets waiting, and probably implement
> some ordering (maybe as simple as FIFO) for the waiting sockets.
I agree that these are definitly issues. However, I think UDP blocking may
actually improve some of the fairness issues. Right now, if a process loops
doing UDP writes without any application-level sleeping scheme on failed
writes, your system becomes really loaded. UDP blocking would improve
fairness in some sense by letting other processes run while the queue
drains.
As for efficiency, I agree that the per-packet send overhead will be
larger. I'm not sure it'll be large enough to become a problem, though.
> All in all I think this approach would only help a bit if
> if you were allowed to queue in the socket buffer
> (on which you can think of having some control, because you either
> opened the fd yourself or you inherited it from some parent),
> in addition to the device queue.
Could you explain this a little more? I think I know where you're going
with this, but I'm not sure :-)
Thanks,
Lars
--
Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
S/MIME Cryptographic Signature
