Date: Wed, 14 Mar 2001 07:39:50 +0100 (CET) From: Luigi Rizzo <luigi@info.iet.unipi.it> To: Lars Eggert <larse@ISI.EDU> Cc: net@FreeBSD.ORG Subject: Re: Changing UDP select() behavior Message-ID: <200103140639.HAA14416@info.iet.unipi.it> In-Reply-To: <3AAEBEAE.F823CB8E@isi.edu> from Lars Eggert at "Mar 13, 2001 04:43:26 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> 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). 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. 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. cheers luigi > I'm considering changing this, so that a select-to-write on a UDP socket > will block until queue space becomes available. (I don't think this would > violate UDP semantics, but is a big enough change to warrant a new sockopt > to enable it.) > > Has this been considered/implemented in any OS? Does anyone see any serious > problems with it? Feedback greatly appreciated! > > Lars > -- > Lars Eggert <larse@isi.edu> Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California Content-Description: S/MIME Cryptographic Signature [Attachment, skipping...] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103140639.HAA14416>