[HN Gopher] Let's code a TCP/IP stack
       ___________________________________________________________________
        
       Let's code a TCP/IP stack
        
       Author : peter_d_sherman
       Score  : 155 points
       Date   : 2021-06-27 18:55 UTC (4 hours ago)
        
 (HTM) web link (www.saminiir.com)
 (TXT) w3m dump (www.saminiir.com)
        
       | baby wrote:
       | Is there something similar but in python or rust or go? Not
       | really keen on reading C.
        
         | fdr_cs wrote:
         | Jon Gjengset here implements TCP in rust. It's long, but it is
         | very good https://youtu.be/bzja9fQWzdA
        
       | dpweb wrote:
       | Notice these classic technologies. They're SIMPLE. That got lost
       | in later development up the stack.
        
         | naikrovek wrote:
         | I don't think I would describe TCP/IP as "simple". there are
         | parts of the spec that contradict each other! it's impossible
         | to implement fully.
        
           | netr0ute wrote:
           | The layer system used by TCP/IP (layer 2 -> 3 -> 4) makes it
           | "simpler" because everything can be compartmentalized without
           | worrying because it was designed to be that way. The real
           | problem comes when you use TCP/UDP for higher level protocols
           | and that's where the real difficulty is.
        
             | tptacek wrote:
             | There's really no such system. In TCP/IP, we refer to
             | "layer 3" and "layer 4" protocols, in reference to OSI, but
             | TCP/IP isn't an OSI protocol, the lines between L2 and L3
             | are blurred by things like ARP and DHCP (or completely
             | eliminated in overlay networks and multicast), and none of
             | the rest of the layers are even informally specified for
             | TCP/IP.
             | 
             | If all you're saying is that TCP/IP has, among its many
             | goals, a separation of concerns, sure. But most major
             | systems designs have separations of concerns.
        
           | l33t2328 wrote:
           | Can you elaborate?
        
         | eatonphil wrote:
         | Ethernet and IP are simple. But TCP is super complex to me with
         | all the state management and buffers and sliding windows. It
         | works well but I find it terribly daunting to dig into (I've
         | tried a few times, and still aim to succeed sometime).
        
       | [deleted]
        
       | [deleted]
        
       | odddog309 wrote:
       | something similar in rust
       | https://www.youtube.com/watch?v=bzja9fQWzdA
        
       | eatonphil wrote:
       | This is an awesome reference but I wish the code was shown as
       | part of the tutorials.
       | 
       | The Github code today is somewhat more complicated to follow.
       | 
       | If you know of any tutorials that walk through a TCP/IP stack
       | with all relevant code I'd love to hear of it.
        
         | johndoe0815 wrote:
         | In addition to the Stevens books already mentioned, there's
         | also volume 2 of Comer's Xinu OS book:
         | 
         | Operating System Design, Vol. 2: Internetworking with Xinu,
         | ISBN-13: 978-0136374145 (https://www.amazon.com/Operating-
         | System-Design-Vol-Internetw...).
         | 
         | Unfortunately, this book was written in 1987, so it's a bit
         | dated (e.g. no IPv6). I think it's still useful to learn the
         | basics of a TCP/IP implementation.
        
         | belter wrote:
         | Not a tutorial but did you look at PicoTCP ?
         | 
         | https://github.com/tass-belgium/picotcp
        
           | tcptomato wrote:
           | That version is abandoned and has quite a few severe bugs.
           | There is a GPL fork which is maintained
           | https://github.com/virtualsquare/picotcp
        
         | kqr2 wrote:
         | There is also a book : TCP/IP Lean
         | http://www.iosoft.co.uk/tcplean.php
        
         | count wrote:
         | Have you seen Richard W. Stevens book TCP/IP Illustrated?
         | Specifically volume 2 'the Implementation', which is, I think
         | what you're looking for (albeit slightly dated).
        
           | eatonphil wrote:
           | Yes I own the series but their focus is a little more on
           | completeness. I know I'm getting picky :) but TCP is pretty
           | complex so I keep looking out for the most minimal code and
           | walk through to understand all the state management and other
           | flow.
        
       | GeorgeTirebiter wrote:
       | Have a look at a TCP/IP stack written for ham radio, originally
       | for CP/M: http://www.ka9q.net/code/ka9qnos/
        
         | ofrzeta wrote:
         | Nostalgia anecdote: we used KA9Q as the routing software on a
         | 286 PC with an ISDN uplink.
        
       | splittingTimes wrote:
       | Coming from C/C++ and Having worked for 5 years within the java
       | world now, i must admit that the naming "conventions" and
       | variable abbreviation in c code or more specifically Linux kernel
       | code form a high entry barrier for me. Why is it so hard to write
       | things out? We all look up to the various Linux philosophies
       | (keep it simple, do one thing, etc), but to me it feels that this
       | kind of code style is not written with a human reader in mind,
       | but comes from the programmer perspective of "what is the
       | shortest way and type as few characters as possible."
       | 
       | This kind of overhead seems so unnecessary and alienating.
        
         | theamk wrote:
         | I think the name shortening is very common in practically every
         | science - and when we are not restricted to ASCII it is even
         | worse, you would see mostly single letter names, combined with
         | subscripts, superscripts, fonts, extra alphabets like Greek and
         | so on.
         | 
         | At least things like ifr_flags are easy to read, easy to type,
         | and unique enough you ca search for them.
        
       ___________________________________________________________________
       (page generated 2021-06-27 23:00 UTC)