From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] Nagle algorithm From: nigel@9fs.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-aaelpgdyemyflvekjbjvfnxhch" Message-Id: <20011126110957.7904219A1C@mail.cse.psu.edu> Date: Mon, 26 Nov 2001 11:09:33 +0000 Topicbox-Message-UUID: 291aad1e-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-aaelpgdyemyflvekjbjvfnxhch Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Depends on your implementation of write(). --upas-aaelpgdyemyflvekjbjvfnxhch Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by cpu; Mon Nov 26 11:13:35 GMT 2001 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.20.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 9AF8619A11; Mon, 26 Nov 2001 06:08:11 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from cesium.clock.org (cesium.clock.org [216.240.40.205]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 8434C19A0C for <9fans@cse.psu.edu>; Mon, 26 Nov 2001 06:07:35 -0500 (EST) Received: by cesium.clock.org (Postfix, from userid 42) id 08895C7901; Mon, 26 Nov 2001 03:07:28 -0800 (PST) To: 9fans@cse.psu.edu Subject: Re: [9fans] Nagle algorithm References: <20011123115816.4863819A7E@mail.cse.psu.edu> From: "Sean M. Doran" In-Reply-To: <20011123115816.4863819A7E@mail.cse.psu.edu> (forsyth@caldo.demon.co.uk's message of "Fri, 23 Nov 2001 11:58:13 0000") Message-ID: Lines: 24 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (sparc--netbsd) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.7 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Help: List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Mon, 26 Nov 2001 12:07:28 +0100 forsyth@caldo.demon.co.uk writes: > ... Nagle's algorithm for coalescing short segments, > which is the one that seems ill-advised to me So, how many packets should the following code segment generate? #include /* for int usleep(useconds_t microseconds); */ for(i=0; i < 200; i++) { write(tcpfd, "a", 1); usleep(100); } > i do find that quite a lot of this smacks of trying to > compensate for inadequate data provided by the protocol or the network. Abstraction and information-hiding are usually considered helpful. Who wants to muck around with RTT and pMTU in an application which just might happen to write to a TCP connection? Perhaps cat(1) isn't complicated enough yet? Sean. --upas-aaelpgdyemyflvekjbjvfnxhch--