Date: Tue, 15 Dec 1998 11:15:09 -0700 From: Wes Peters <wes@softweyr.com> To: Marc Slemko <marcs@znep.com> Cc: Michael Robinson <robinson@netrinsics.com>, fenner@parc.xerox.com, freebsd-net@FreeBSD.ORG Subject: Re: MLEN < write length < MINCLSIZE "bug" Message-ID: <3676A72D.E5FDF673@softweyr.com> References: <Pine.BSF.4.05.9812150824460.22888-100000@alive.znep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Marc Slemko wrote:
>
> No, it really is a bug.
>
> It is inherently broken to write multiple packets for one write() when the
> size of the write is far less than the MTU (well, the "effective MTU")
> unless you have extreme extenuating circumstances.
I think you're confusing your ASSUMPTION that 1 write == 1 packet with
any requirement for this to be true. Nothing in the code or the doco
promises this behavior, so it's not a bug, it's just a design decision.
> It may not be a bug covered by any spec, but for people trying to write
> useful network apps it shoots them in the head. It is still a bug.
In the vast majority of cases, it's the right choice to make, too. In
the few examples of network code that need to be highly responsive, it's
a terrible choice. These applications seem to be in the minority, since
so many find the system useful as it is.
I've followed this discussion and strongly agree that the "right way" to
do this is to provide a socket option to turn off the default buffering
on a per-socket basis. This would make my packet-throughput program
actually WORK. ;^)
Since the default is right for the vast majority of network programs,
the small added complexity of the sock option shouldn't be too horrible
to address.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://www.softweyr.com/~softweyr wes@softweyr.com
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?3676A72D.E5FDF673>