9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Nagle algorithm
Date: Mon, 26 Nov 2001 14:28:23 -0500	[thread overview]
Message-ID: <200111261928.OAA12147@augusta.math.psu.edu> (raw)
In-Reply-To: <20011126112312.80AC9C7901@cesium.clock.org>

In article <20011126112312.80AC9C7901@cesium.clock.org> you write:
>| If that's a problem for your cat, you could convince
>| your cat to use Bio; and retain your abstraction as well.
>
>And how does your write(2) or wrapper around write(2)
>know what the present maximum segment size is, given
>that it can be altered at any time via a local interface
>MTU change or a change in the path MTU?

Why does my write(2) care?  If my write-wrapper picks a decent
default, does it matter much?  I suppose one could argue that
there might always be a runt packet on the end when the buffer
is written, depending on, eg, the MTU and size of the buffer,
but I claim that expense will be amortized over the lifetime
of the connection.

>How does pulling that into a wrapper which is used
>almost universally fundamentally differ from retaining
>in the TCP code with a system call which allows it to
>be turned off on those rare occasions you want to do so?

It has to do with abstraction, on one hand, and proper seperation
of function.  The TCP has no business trying to guess what my
application is doing; that's for my application to decide.  TCP
should be abstracted away from that stuff.

	- Dan C.



  reply	other threads:[~2001-11-26 19:28 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-26 11:23 Sean M. Doran
2001-11-26 19:28 ` Dan Cross [this message]
2001-11-27  8:57   ` Steve Kilbane
2001-11-27 14:39     ` Boyd Roberts
2001-11-27 19:56       ` Steve Kilbane
2001-11-27 22:26         ` Boyd Roberts
2001-11-29 16:55           ` Matt
2001-11-27 10:16   ` Thomas Bushnell, BSG
2001-11-27 18:59     ` Dan Cross
  -- strict thread matches above, loose matches on Subject: below --
2001-11-29 17:33 jmk
2001-11-27 11:28 forsyth
2001-11-27 11:00 forsyth
2001-11-27  5:31 David Gordon Hogan
2001-11-26 12:07 Fco.J.Ballesteros
2001-11-26 11:52 Fco.J.Ballesteros
2001-11-26 11:09 nigel
2001-11-24 10:48 forsyth
     [not found] <rsc@plan9.bell-labs.com>
2001-11-24  5:32 ` Russ Cox
2001-11-24 20:04   ` Scott Schwartz
2001-11-24  3:26 Scott Schwartz
2001-11-23 11:58 forsyth
2001-11-26 11:07 ` Sean M. Doran
2001-11-26 19:22   ` Dan Cross
2001-11-27 10:16     ` Thomas Bushnell, BSG
2001-11-27 18:55       ` Dan Cross
2001-11-23  9:44 forsyth
2001-11-26  9:59 ` Thomas Bushnell, BSG
2001-11-22 13:24 forsyth
2001-11-22 13:29 ` Boyd Roberts
2001-11-23  9:34 ` Thomas Bushnell, BSG
2001-11-26 19:13   ` Dan Cross
2001-11-21 23:38 David Gordon Hogan
2001-11-21 23:59 ` Andrew Simmons
2001-11-22  9:57   ` Thomas Bushnell, BSG
2001-11-21 23:20 Andrew Simmons
2001-11-26 10:57 ` Sean M. Doran
2001-11-26 19:11   ` Dan Cross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200111261928.OAA12147@augusta.math.psu.edu \
    --to=cross@math.psu.edu \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).