Re: TCP MSS issue

• Previous message: Heny Townsend: "Re: Non-Root Process Backtrace of Itself?"
• In reply to: Walter Roberson: "Re: TCP MSS issue"
• Next in thread: Walter Roberson: "Re: TCP MSS issue"
• Reply: Walter Roberson: "Re: TCP MSS issue"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sat, 25 Dec 2004 23:32:16 -0700 (MST)

In article <cql0fs$6ib$1@canopus.cc.umanitoba.ca>,
Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:

>:I_SRDOPT is an option for Streams and not for TCP. It works if a
>:transport protocol honours this option. TCP is certainly not one of it.
>
>Emil, TCP can (and has been) implimented in terms of STREAMS.

As far as I know and recall, there have been two major implementations
of TCP/IP in System V STREAMS. The first was done by people at Lachman
(perhaps Steve Alexander?) for AT&T and was part of what wrecked AT&T's
suit against BSDI when it came out that AT&T had been shipping the
Regent's code without the Regent's copyright legends. Judging from
my diffs with with the SVR4 source, it consisted of the BSD 4.3 TCP/IP
of various flavors jammed into STREAMS modules. The second was the
from-scratch Mentat code that Sun shipped in a paniced reaction to
that legal stuff.

>The following are from the SGI IRIX man pages:

Please check the IRIX kernel source instead of trying to infer from
man pages, which themselves were related to BSD and SV man pages.
I think you'll find that IRIX STREAMS TCP/IP was really a wart on top
of and beside good old 4.3 BSD SOCKETS TCP/IP, including Sam Leffler's
protocol switch, Van Jacobson's slow-start, ack-pacing, and
header-predicting, etc.

Well, there is (or was?) also the other, later STREAMS-related wart
underneath among the interfaces, ostensibly to support SAPs. What was
that over elaborate, committee designed, utter disaster of a driver
abstraction called? I though it stupid because it required upper
layers to do things like handle the differing bit orders of IEEE MAC
addresses for 802.3 vs. FDDI.

(Survey the $author$ tags in RCS logs of the IRIX kernel TCP/IP and
STREAMS code to see the basis of those claims.)

> For STREAMS files [see intro(2)], the operation of write is determined by
> the values of the minimum and maximum nbyte range (``packet size'')
> ...

That seems to be confusing the SRV3 STREAMS in IRIX with the BSD
SOCK_STREAMS also in IRIX--at least as of IRIX 6.?.

>There is no mention at all of sockets in the write(2) man page, but the
>section on STREAMS describes fragmentation into packets. Would it not
>be rather strange to describe in detail packet fragmentation for the
>obscure STREAMS and yet not even mention sockets at all, let alone
>describe their fragmentation rules, unless sockets are indeed a kind of
>STREAM ?

Things are indeed strange, undreampt of things in heaven and earth.
20 years ago were already "streams," "STREAMS," "SOCK_STREAM," and
many other kinds of canals, rivers, creeks, pipes, aqueducts, and
other flowing things, all different and related.

As I see things, no one in their right minds writing a STREAMS module
for the TCP state machines would handle dividing data into segments much
differently than the BSD code does. TCP is what it is. If you are
building T/TCP, UDP, RDP, or something else, you might do other things.

I recognize the names of some contributors to this thread. Greetings.
You guys are still far more gentle than I am.

Vernon Schryver vjs@rhyolite.com

• Previous message: Heny Townsend: "Re: Non-Root Process Backtrace of Itself?"
• In reply to: Walter Roberson: "Re: TCP MSS issue"
• Next in thread: Walter Roberson: "Re: TCP MSS issue"
• Reply: Walter Roberson: "Re: TCP MSS issue"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]