From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Nagle algorithm
References: <20011123115816.4863819A7E@mail.cse.psu.edu>
From: "Sean M. Doran" <smd@cesium.clock.org>
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: <ytu1vhu6xb.fsf@cesium.clock.org>
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
Date: Mon, 26 Nov 2001 12:07:28 +0100
Topicbox-Message-UUID: 29150f1c-eaca-11e9-9e20-41e7f4b1d025

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 <unistd.h>
    /* 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.