Show HN: MicroTCP, a minimal TCP/IP stack
github.com
github.com
1. There is no license, so it's proprietary code.
2. It's a student project, you shouldn't use it for anything.
I'm a graduate, should you use it if I write it?
I don't think there's any reason not to experiment with this any more than similar ShowHN hobby work from anyone else. i.e. follow its progress, maybe toy with it in your own hobby thing.
And honestly, I knew more about how to write a TCP/IP stack when I was a student than now. If I could do a better job now it would only be from some experience writing other code to RFC spec.
An HTTP/echo server you control is great for the bare essentials, but there are so many mind-boggling ways things can go wrong in the real world. I think the only way to catch those edge cases (and even so you'll never catch them all!) is to use it on as many different devices for as many real world applications as possible.
> It wasn't clear from the article if you were planning on working on this further or leaving it as is
At the moment I'm working on it on and off in my spare time. I think I will continue that way until all major features are done and stable
> An HTTP/echo server you control is great for the bare essentials, but there are so many mind-boggling ways things can go wrong in the real world. I think the only way to catch those edge cases (and even so you'll never catch them all!) is to use it on as many different devices for as many real world applications as possible.
Yes, I'm realizing that. From the beginning I've been thinking about going the unit test route but couldn't find a way to make it work. Thanks for the feedback!
http://www.vpri.org/pdf/tr2007008_steps.pdf
It's not really intended for production use, more as a demo of a new experimental programming language.
What would you call this paradigm?
Ian Piumarta (this researcher) calls it "self implementing". https://www.piumarta.com/cv/bio.html
My best effort so far is "example driven programming", which is turrible.
I did something similar for HL7 specifications, at about the same time. Our consultants (what the kids today would probably call business analysts) would hammer out an "HL7 interface" document. (Think human readable OpenAPI for the time.) It'd serve as an actual contract, between us and the hospital, of sorts.
Being lazy, I wrote a parser (not BNF based, like Piumarta's work) which scrapped the "interface" and generated code. Implemented in minutes, instead of days or weeks.
I've since applied that strategy to other domains, with similar results.
But I have the hardest time describing this paradigm. Even when people see demos, they don't quite get it. This stuff is supposed to be hard, right? Surely I'm cheating somehow.
Naively, I've been thinking that if I coined an insipid new phrase, maybe it could become an inscrutable meme. Like "Agile Methodology" and "Extreme Programming" did. Catnip for PHBs.
That (uControllers and small systems in general) should be among the best use cases as there is obviously a much higher demand for a low footprint network stack in that field, also with an eye to Single Pair Ethernet, should it become cheaper and widely supported in common uCs in the future.
Of course it needs tap but it might not be too hard to get it to work with an phy driver directly.
mTCP:
- Read the spec(s)
- Learn the OS APIs deeply
- Look at a bunch of real network data in e.g. Wireguard
I think you probably meant data in e.g. Wireshark?
But another good suggestion (or maybe what you meant) might be to look at 'real' (production) networking code in e.g. Wireguard, I imagine.
So the first step I would do to start on a TCP/IP stack would be "how to open a raw socket" (granted you have to know the magic phrase here). There's also tons of "how to implement TCP stack" articles (same for ethernet etc) that probably are good starting points if I didn't know that magic phrase. The other thing is to find people to talk to who know more than you to answer those questions.
Once you have that, you can setup a real TCP socket on one end and a raw socket client on the other & then the same thing in reverse. Then look up the TCP/IP framing on Wikipedia (+ read up on the broad overview of how TCP works and the various parts). Once you have the framing implemented, try implementing the basic sequence to establish a connection. Then keep noting what features a full TCP stack has, which are required, & which are missing from my implementation (that's when I'd start reaching for the standards that everyone references).
Of course, if you want to do something novel beyond just "hey I have confidence that I can implement such a stack myself" (e.g implementing something with certain performance characteristics) that requires a deeper understanding of how things work and a good filter on possible ideas & which ones are going to likely work out the best (that is gained through expertise, creativity & intelligence)
My favourite programming book is structured like this "elements of computer systems" also referred to as "from nand to Tetris"
As for db's/other interesting things, I haven't read them myself but this site seems solid https://build-your-own.org/. If anyone has any real experience with this site, I would love to hear it!
After getting into university I decided to build an interpreter[0]. For someone who didn't even have the notion of a parser, it just felt like an unaproachable task. Even though, I sticked to it and the architecture became clear in time. That's another thing, even if you try to build something and miserably fail at it at each iteration, you still get better at it. The feeling of the task being too vast and daunting is just a feeling and knowing there's something on the other side makes it easier to power through it.
Hope to see your database on HN someday! :^)
https://web.archive.org/web/20060615041317/http://www.sics.s...
uIP is an implementation of the TCP/IP protocol stack intended for small 8-bit and 16-bit microcontrollers. It provides the necessary protocols for Internet communication, with a very small code footprint and RAM requirements - the uIP code size is on the order of a few kilobytes and RAM usage is on the order of a few hundred bytes.
https://github.com/adamdunkels/uip
https://en.wikipedia.org/wiki/UIP_(software)
(I believe uIP was extracted and improved upon from Contiki, a C64 OS with TCP/IP support written in C in 2002: https://www.c64-wiki.com/wiki/Contiki)