From owner-freebsd-net Tue Dec 15 10:15:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA00625 for freebsd-net-outgoing; Tue, 15 Dec 1998 10:15:32 -0800 (PST) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from obie.softweyr.com ([204.68.178.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA00611 for ; Tue, 15 Dec 1998 10:15:30 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id LAA17430; Tue, 15 Dec 1998 11:15:10 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <3676A72D.E5FDF673@softweyr.com> Date: Tue, 15 Dec 1998 11:15:09 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Marc Slemko CC: Michael Robinson , fenner@parc.xerox.com, freebsd-net@FreeBSD.ORG Subject: Re: MLEN < write length < MINCLSIZE "bug" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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