For those that rather learn how to implement it in a safer language, Fuchsia's TPC/IP stack is written in Go.
Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
21–30 of 50 posts
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#22Not directly related to the article, but there is an experimental effort to develop a userland TCP stack in .NET right now. It's interesting to see how this looks in a higher level language. https://github.com/ProjectMagma/Magma
In addition to that, here are some other examples.
Go in Fuchsia,
https://fuchsia.googlesource.com/third_party/netstack/
Oberon in Oberon (network stack but not TCP/IP though)
https://www.inf.ethz.ch/personal/wirth/ProjectOberon/Sources...
Active Oberon in A2 - BlueBottle OS (TCP/IP stack)
https://github.com/btreut/a2/blob/48dcfc1f1a6ed2bec110ca3af3...
Mesa at Xerox PARC (Courier RPC, XNX)
http://www.bitsavers.org/pdf/xerox/mesa/3.0_1977/listing/
Sing# on Singularity
https://archive.codeplex.com/?p=singularity
Start at sourceCode\sourceCode\base\Libraries\System.Net\Sockets
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#23Earlier quoted context omitted.
I tend to use int for loops (where I know there will always be less than 2^16 iterations!), return codes etc. purely because it allows the compiler to pick a fast word size everywhere (e.g. if somebody compiles your code for AVR, and your loops are all int32_t, your API returns int32_t, they're gonna have a worse time). Otherwise, I fully agree.
Maybe you could use int_fast16_t? (That means, pick the fastest signed integer type which is at least 16 bits.) Of course, "int" is less typing than "int_fast16_t". But, int_fast16_t possibly makes it more obvious why you've chosen the type you did (i.e. you only need 16-bits, but aren't relying on any overflow so a bigger type can freely be substituted if that gives better performance.)
That's certainly a valid approach, but I've never actually seen those used in practice. I guess, like me, people are lazy and prefer typing just int, which is guaranteed to be at least 16 bits, and is generally the fastest int type (well, excepting some 8-bit archs.. :P).
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#24Operating System Design: Internet Working With Xinu by Douglas Comer (1987) is a nice explanation with lots of C code of how to add a networking stack to an operating system, in this case his educational unix-inspired XINU.
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#25Not directly related to the article, but there is an experimental effort to develop a userland TCP stack in .NET right now. It's interesting to see how this looks in a higher level language. https://github.com/ProjectMagma/Magma
In addition to that, here are some other examples. Go in Fuchsia, https://fuchsia.googlesource.com/third_party/netstack/ Oberon in Oberon (network stack but not TCP/IP though) https://www.inf.ethz.ch/personal/wirth/ProjectOberon/Sources... http://www.projectoberon.com/ Active Oberon in A2 - BlueBottle OS (TCP/IP stack) https://github.com/btreut/a2/blob/48dcfc1f1a6ed2bec110ca3af3... https://github.com/btreut/a2 Mesa a…
Mirage OS written in ocaml has a tcp/ip stack as well. The marshal and unmarshal code is very succint compared to C implementations.
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#26Earlier quoted context omitted.
I have another TIL for you... maybe you're a desktop/server developer... there are many embedded processor platforms where a byte is not 8 bits. TI's C2000 microcontrollers - a byte is 16 bits. Other TI DSPs also have 16 bit bytes.
Did you mean char?
In C, char is defined to be 1 byte. So its the same here. But they have 16-bit bytes. This is one of the rare cases where byte != octet.
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#27For those that rather learn how to implement it in a safer language, Fuchsia's TPC/IP stack is written in Go. https://fuchsia.googlesource.com/third_party/netstack/
Isn’t garbage collection going to introduce jitter?
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#28Earlier quoted context omitted.
In addition to that, here are some other examples. Go in Fuchsia, https://fuchsia.googlesource.com/third_party/netstack/ Oberon in Oberon (network stack but not TCP/IP though) https://www.inf.ethz.ch/personal/wirth/ProjectOberon/Sources... http://www.projectoberon.com/ Active Oberon in A2 - BlueBottle OS (TCP/IP stack) https://github.com/btreut/a2/blob/48dcfc1f1a6ed2bec110ca3af3... https://github.com/btreut/a2 Mesa a…
Mirage OS written in ocaml has a tcp/ip stack as well. The marshal and unmarshal code is very succint compared to C implementations.
Thanks, forgot about that one, it is even part of Docker for macOS.
https://blog.docker.com/2016/05/docker-unikernels-open-sourc...
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#29For those that rather learn how to implement it in a safer language, Fuchsia's TPC/IP stack is written in Go. https://fuchsia.googlesource.com/third_party/netstack/
Isn’t garbage collection going to introduce jitter?
Not necessarily, there are several OSes written in GC enabled systems programming languages.
Just because a language has a GC it doesn't mean it is the only means to allocate memory.
Go also allows for global statics, stack and plain old C style manual allocations. It is a matter to learn how to use them.
And make use of profilers as well.
For example, on performance critical paths always use a standard for loop, never a for range one.
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#30Earlier quoted context omitted.
Unless you are adding TCP to your CDC6600 or PDP-8, bytes are 8 bits. Any suggestion to the contrary in standards is fantasy. That said, since the next field is a uint16_t, you may as well stay in Rome and call them uint8_t. short really is variable on some live architectures. (Ok, or some DSPs only address words larger than 8 bits, but there's no reason for your compiler not to pick up the slack.) Also, TIL that __a…
I don't see any reason in modern C to use int/short/long over explicit int32_t/int8_t/int64_t other than they're shorter to type.
Where can I read tips like that about modern C, would you have a book to recommend or a blog to follow? Thank you