My first job was at Westinghouse instrumenting a nuclear power plant. Our entire hardware-software package was a freebie given to the customer as part of a $200 million refueling contract (and that's in 1988 dollars). We, a team of 10, created a bespoke application stack which was effectively a web browser. The client machines were Sun 3 workstations. The server was some industrial mini computer that didn't have a TCP/IP stack - so we did in fact have to roll our own network stack.
I would seriously recommend against building your own network stack for production use. Or writing your own web server for production use. Or database (whatever SQL or NoSQL) also for production use.
These sort of things are more complicated than you could expect and have plentiful pitfalls. Whatever you can do in reasonable amount of time is probably not that good compared to existing alternatives.
If you have actually pressing reason to build one and are ready and have means to spend time and effort on it go ahead. But carefully consider the effort needed...
Monoculture. It's like when all bananas used to be clones of each other and a disease wiped out the whole species.
Everyone should build their own ** is the general advise I would give just about anything. Otherwise it is hard to appreciate how much effort it goes into things that we take for granted.
Everything looks simple from the outset until you try to build it yourself.
This is just an opinion and not a very sensible one at that. The Linux TCP/IP stack is one of the most scrutinized network stacks in the world and more than likely free of bugs that coud lead to a server takeover.
A while back I wrote an FPGA-based minimal network stack to work with the MRMAC hard IP of an AMD VC1902 with basically the same functionality: ARP, IPv4, ICMP Echo reply and UDP send/receive. I added the bare bare minimum to get UDP GRO working on the receiver side (Linux).
I also enjoyed the learning experience and works perfectly fine at up to 100G. But I definitely appreciate that I didn't have to go through the same pain under Linux where this stuff just works.
Good to see that people still have this spirit of rolling their sleeves up and doing something like this for fun. Underneath it there is a very real point about mono-cultures and the increased magnitude of the impact of a risk, although more eyes checking one implementation should reduce the probability.
Back in the 8-bit days, we all wrote our own kernel process schedulers in order to make simple games. If you had an Apple II and wanted music, you'd need to make yours a hard real time one as well.
Prediction: as agentic code generation gets better, more and more code will be written JIT for it to be executed for security reasons. The engineer of the future is not only the one who uses agents to code, he uses agents to code each time "the" program is ran.
Huh, I thought the thesis was going to be "... because it's a good learning experience everyone should do to understand how networking works" but the reason offered comes down to security. However, I'm going to go with what I had thought originally and actually make this an assignment for students. Anyone have experience witht that, could this be done in a semester?
Much more fun on microcontrollers!
Looks at frankly staggering number of CVEs made by people missing some edge case in networking
"Please don't"
[dead]
This article might be a bit tongue-in-cheek but it's actually something I've been thinking seriously about for a while. I can imagine a future where every country and company writes their own operating system and that might actually be a very good thing. There is a security advantage in not using popular technology stacks and rebuilding everything public-facing in-house. Because with Mythos-level AI capabilities, it is almost guaranteed that anyone with access to Mythos/Cyber can find a zero day in your stack. If your stack is proprietary and bespoke with no public access to source code it's much harder to find vulnerabilities, because they can only probe your public facing interfaces.