
TCP in 30 instructions (1993) - adamnemecek
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg00133.html
======
tptacek
This is a very famous post, and Van Jacobsen is the archetypical networking
systems programming bad-ass. Important context here though: this is just the
per-segment receive processing piece of TCP; it's describing a very simple
fast path that segments can take, but not all the TCP logic!

~~~
FuckFrankie
Wouldn't "all the TCP logic" be the entire internet?

~~~
randyrand
The internet is a very large and general term. It comprises millions of
servers, routers, generally includes things like web browsers, http, etc.

TCP is just one protocol of the thousands of protocols used for the internet,
typically to carry other protocols. UDP is also used on the internet.

"not all the logic" means that this implementation is not a full
implementation of the TCP protocol.

Check out:
[http://en.wikipedia.org/wiki/Internet_protocol_suite](http://en.wikipedia.org/wiki/Internet_protocol_suite)
[http://en.wikipedia.org/wiki/OSI_model](http://en.wikipedia.org/wiki/OSI_model)

~~~
ZoF
Dewees?

------
wslh
If you liked this post you might like the "Appendix E: Extended Example: A
Tiny TCP/IP Done as a Parser" by Ian Piumarta. The paper is available at:
[http://www.vpri.org/pdf/tr2007008_steps.pdf](http://www.vpri.org/pdf/tr2007008_steps.pdf)

------
grannyg00se
I love the opinionated writing style. I wish I knew more about this so I could
relate to the comments about the "compiler braindamage", "mbuf chain
stupidity", and "netipl software interrupt bs".

~~~
darbelo
The "mbuf chain stupidity" refers to the way memory buffers are handled in the
kernel. His implementation uses 'pbufs' to store a single packet contiguously
in kernel memory. This is in contrast to BSD[1], where a packet could span
multiple 'mbufs' which were 'chained' into a linked list.

You can "man 9 mbuf" on your nearest BSD derivative to glean a bit more
information about what he is opposing. Today's mbufs are not quite the same as
they were back then, but the parts that he hated are still there :)

[1] "my kernel looks nothing at all like any version of BSD"

~~~
laichzeit0
For a walk through of the BSD TCP/IP source code there's also Steven's TCP/IP
illustrated volume 2. The first few chapters painstakingly go through mbufs
and exactly how the data structure is implemented and used. Much of this won't
apply to current kernels but it's probably close enough for what Van Jacobson
is talking about.

[http://www.amazon.com/TCP-IP-Illustrated-Implementation-
Vol/...](http://www.amazon.com/TCP-IP-Illustrated-Implementation-
Vol/dp/020163354X)

------
anonu
I am curious to know if today's modern TCP stacks (windows, popular linux
distros,etc..) are coded with the same approach. Does anyone know?

~~~
bodyfour
More or less, yes.

In the original TCP implementations from the early 80s, performance was
(understandably) not the main priority.. they just wanted to get it working
first. Also, nobody was sure what networking protocols would become popular
(IP? OSI? XNS?) so a lot of work went into making everything as flexible as
possible. This reached an apogee with AT&T's "STREAMS" subsystem (a competitor
to the sockets API for writing networking code on UNIX) which was very
flexible but also extremely complicated.

What Van Jacobson's work was saying is "look guys: by paying close attention
to the fastpath you _can_ saturate your 10Mbps network with TCP traffic" I'm
sure everybody who has written a TCP stack has seen this email and has taken
the tricks to heart.

These days not all of the tweaks might be still relevant. For instance, the
hardware is probably doing the hardware checksum for you. However, the spirit
of "do as little as possible in the fastpath" is certainly still followed in
modern stacks.

~~~
oofabz
Just as a historical note, classic Mac OS (versions 7-9) used STREAMS for TCP,
in the Open Transport networking API. Sockets were provided as a wrapper
around STREAMS, which worked about as well as you might expect. It had its
fans but most of us were pleased to get real sockets in Mac OS X.

~~~
bodyfour
I wasn't aware classic MacOS worked that way. The "sockets-emulated-over-
STREAMS" was the standard way of doing things in SVR4-based UNIXes. In the
early-to-mid 90s this gave them a poor reputation among early web admins since
they just didn't handle high rates of connections as well as BSD or even the
early linux stacks.

In the case of Solaris, this was largely fixed in the 2.6 release where they
went back to a sockets-based stack and ran the STREAMS stack in parallel.
(Actually this was originally supplied as a semi-supported patch to 2.5.1
since the scalability of the network stack was becoming a critical issue at
large customers) Many of the OS-supplied services (like rpcbind I think) still
used the STREAMS API but the 99.9% of external software that used the sockets
API now had a fast native path to the network.

As far as I'm aware this is still the state there today, with STREAMS probably
still existing for compatibility but basically ignored by everyone.

There were some interesting things Solaris did with STREAMS.. for instance
telnetd and rlogind would just push a kernel-land module that would copy data
between the pty and socket. This way you didn't have to make the
kernel->user->kernel->user transition on every keystroke. In the heyday of
shell accounts this was terrific. Of course these days CPUs are so much faster
and everyone uses ssh anyway so it wouldn't be a useful optimization.

STREAMS was an interesting experiment, but I don't mourn its passing at all.

~~~
mietek
In the age of System 6 and early System 7, before Open Transport, there was
MacTCP, an add-on TCP stack, originally sold by Apple for $2500.

[http://en.wikipedia.org/wiki/MacTCP](http://en.wikipedia.org/wiki/MacTCP)

[http://tidbits.com/iskm/iskm3html/pt4/ch17/ch17.html](http://tidbits.com/iskm/iskm3html/pt4/ch17/ch17.html)

------
nashashmi
Might be off topic, but I have always wondered where do these public domain
university emails come from? Was E-mail a public forum back then?

~~~
michaelhoffman
I'm not sure what you mean by "these public domain university emails." This is
an email that has been saved and re-forwarded many times, including to mailing
lists such as the one archived in the main link. Originally it would have been
forwarded by either the sender or one of the recipients.

------
radikalus
Similar topic...

Anyone know of a good short C implementation of TCP that includes SACK?

