--9jxsPFA5p3P2qPhR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Mar 27, 2005 at 03:59:55PM -0500, Thor Lancelot Simon wrote:
> On Sun, Mar 27, 2005 at 10:51:05PM +0200, Emmanuel Dreyfus wrote:
> > Jonathan Stone <jonathan@dsg.stanford.edu> wrote:
> >=20
> > > So, please stop saying that NetBSD's behaviour is "broken".
> >=20
> > All right, so if everyone agree there is no bug to fix, then let's close
> > the PR and forget about it. The "oddity" (am I allowed to call it an
> > oddity?) may deserve an explanation in the man page, though.=20
>=20
> I still don't think that ENOBUFS should be returned.  I think that if we
> run out of space the interface queue packets for non-reliable protocols
> should just be silently dropped.  I'm not really able to read the manual
> page or the quoted parts of the specification as allowing ENOBUFS in this
> case but I think blocking is also wrong.

I agree with this point. ENOBUFS is a form of packet drop, and we're=20
talking about UDP. It's fine for UDP to drop packets. The mere fact that=20
the sender knows it happened is independent.

My one contrary thought, though, is that a sender may behave differently=20
in face of a local transmission error than if it thinks the packet was=20
sent successfully. So some sort of sysctl and socketopt behavior may be=20
best if we change this.

Take care,

Bill

--9jxsPFA5p3P2qPhR
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCR3SeWz+3JHUci9cRAjePAJ9oxR8Q1qHtH+pg6lMHnRlqIxoRwQCghPkT
mNKS8G6/rCzxaLxHvP1pqkk=
=fP5x
-----END PGP SIGNATURE-----

--9jxsPFA5p3P2qPhR--