Live data from Hacker News

Let's code a TCP/IP stack (2016)

saminiir.com

41–50 of 55 posts

Re: Let's code a TCP/IP stack (2016)

#41

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.

[deleted]

Re: Let's code a TCP/IP stack (2016)

#42
post #39

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…

They literally had size limits on variable names back then.

Not just variables. When I was doing 68k assembly, even around year 2000, the assembler had a limit of 8 bytes for all labels. So, functions, branches, jumps, etc all limited to 8 byte labels. I was in college at the time and any sort of external linker or anything was beyond us at the time, so it meant all of our programs were in one monolithic file. It was hard to manage and give meaningful names by hand to labels in a 40k LOC assembly file where every label had to both be unique and only the first 8 bytes mattered.

Re: Let's code a TCP/IP stack (2016)

#43

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…

I feel the same way. This limitation might have made sense in times of teletype, limited variable names and small displays, but that was decades ago! We have powerful IDEs that automatically finish every identifier we write, huge, high-resolution displays and exhaustive online documentation available at all times. I don't see any reason to continue writing code like that: In the comments of every single coding style article posted on HN, people are quick to throw stuff like "code is written once, but read many times" around. Why wouldn't this apply to C or Linux kernel code?

Re: Let's code a TCP/IP stack (2016)

#44
post #26

Earlier quoted context omitted.

ISDN was super fast - I remember playing Warcraft 2 on an ISDN connect with a friend down the street :)

growing up in the UK stuck with 56Kbps modems, when prompted to select network speeds I remember seeing things like ISDN (128Kbps) and T1/T3 Cable (1Mbps) and thinking wow, those Americans have lightning Internet

Oh how the tides have turned.

Re: Let's code a TCP/IP stack (2016)

#45

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.

Jon Gjengset has a series of videos implementing TCP in Rust.

https://youtu.be/bzja9fQWzdA

Re: Let's code a TCP/IP stack (2016)

#46
post #31

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…

C and Unix are from the early 1970s. They date from an era that predates the prevalence of large, bitmapped displays. There is a famous photo of Dennis Ritchie and Ken Thompson at a teletype in 1972 ( http://www.columbia.edu/cu/computinghistory/teletype/ken-and... ). When the luxuries of modern IDEs, bitmapped displays, and high amounts of untapped computational power are unavailable, the programming environment and…

> are from the early 1970s

But why do we still have to suffer in 2021?

Re: Let's code a TCP/IP stack (2016)

#47
post #12

Notice these classic technologies. They’re SIMPLE. That got lost in later development up the stack.

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).

Ethernet was simple, with VLAN.. it isn't so simple anymore..

Re: Let's code a TCP/IP stack (2016)

#48
post #26

Earlier quoted context omitted.

ISDN was super fast - I remember playing Warcraft 2 on an ISDN connect with a friend down the street :)

growing up in the UK stuck with 56Kbps modems, when prompted to select network speeds I remember seeing things like ISDN (128Kbps) and T1/T3 Cable (1Mbps) and thinking wow, those Americans have lightning Internet

You could get ISDN2 installed on domestic premises in the UK. It wasn't cheap though, because as soon as you wanted a bonded 128k channel the cost could become somewhat eye watering for a domestic user (or even a small business).

The good thing though was that you got a guaranteed 64k rather than the vagueries of a 56k modem that in practice never actually worked at 56k, more like 30-45k depending on phone line quality.

On top of that you could (if your wallet was fat enough) get ISDN30 (E1) which was akin to a T1 but ~500k faster.

I did a fair amount of commissioning of these things back in the 90's.

Re: Let's code a TCP/IP stack (2016)

#50
post #47

Earlier quoted context omitted.

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).

Ethernet was simple, with VLAN.. it isn't so simple anymore..

I mean ethernet, the protocol. It just wraps packets with some headers and a checksum. Are you saying it gets more complex than that? (I haven't dug into ethernet much more deeply than I describe).
Post reply on HN