From owner-freebsd-net Tue Dec 15 10:57:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA06485 for freebsd-net-outgoing; Tue, 15 Dec 1998 10:57:55 -0800 (PST) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from alive.znep.com (sense-sea-MegaSub-1-222.oz.net [216.39.144.222]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA06480 for ; Tue, 15 Dec 1998 10:57:52 -0800 (PST) (envelope-from marcs@znep.com) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.1/8.9.1) with ESMTP id KAA06285; Tue, 15 Dec 1998 10:57:19 -0800 (PST) (envelope-from marcs@znep.com) Date: Tue, 15 Dec 1998 10:57:19 -0800 (PST) From: Marc Slemko To: Wes Peters cc: Michael Robinson , fenner@parc.xerox.com, freebsd-net@FreeBSD.ORG Subject: Re: MLEN < write length < MINCLSIZE "bug" In-Reply-To: <3676A72D.E5FDF673@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 15 Dec 1998, Wes Peters wrote: > 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. Erm... "it is a design decision that any user can crash the kernel by doing xxx." You can call that a design decision, I call it a bug in the same way that this is a bug. You can't pretend bugs don't exist by calling them "design decisions". > > > 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. What on earth are you talking about? The "default" is NOT right. There are almost NO programs that benefit at ALL from having a write() of a few hundred bytes split into two TCP packets! It is completely nonsensical to talk about having a socket option to disable this. Now, this doesn't currently cause a major issue with all of the programs around. That doesn't mean it is the right thing to do for them! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message