Date: Wed, 14 Mar 2001 01:06:01 +0000 From: Brian Somers <brian@Awfulhak.org> To: Lars Eggert <larse@ISI.EDU> Cc: net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Changing UDP select() behavior Message-ID: <200103140106.f2E161a09824@hak.lan.Awfulhak.org> In-Reply-To: Message from Lars Eggert <larse@ISI.EDU> of "Tue, 13 Mar 2001 16:43:26 PST." <3AAEBEAE.F823CB8E@isi.edu>
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'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! This'd be nice if it could be made to work. I guess the problem is that you don't actually know if a write() will succeed 'till you try it (and try to allocate an mbuf). Having said this, it would be nice if it was possible to pre-allocate (a small number of) mbufs for a pipe() or socketpair(), giving a reliable SOCK_DGRAM file-descriptor based ipc mechanism. > Lars > -- > Lars Eggert <larse@isi.edu> Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California -- Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org> <http://www.Awfulhak.org> <brian@[uk.]OpenBSD.org> Don't _EVER_ lose your sense of humour ! 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?200103140106.f2E161a09824>