Live data from Hacker News

A full TCP/IP stack in under 200 LoC (and the power of DSLs)

moserware.com

1–10 of 21 posts

Re: A full TCP/IP stack in under 200 LoC (and the power of DSLs)

#4
post #2

Downright impressive. I'm implementing the TCP/IP stack for my OS at the moment, and it's sitting at about 400 lines before TCP (ethernet, IP, DHCP, and ARP). Definitely going to see how I can improve it after this.

Hi Daeken,

That's impressive. Are you writing your OS for study purposes or you have something special in mind? I am interested in knowing as I am planning to do the same and might want to consult you.

Re: A full TCP/IP stack in under 200 LoC (and the power of DSLs)

#5
post #2

Downright impressive. I'm implementing the TCP/IP stack for my OS at the moment, and it's sitting at about 400 lines before TCP (ethernet, IP, DHCP, and ARP). Definitely going to see how I can improve it after this.

Hi Daeken, That's impressive. Are you writing your OS for study purposes or you have something special in mind? I am interested in knowing as I am planning to do the same and might want to consult you.

There's a post about the background and motivation for the OS (Renraku) here: http://daeken.com/renraku-future-os

If you want to talk more about it or OS dev in general, feel free to ping me on IRC (Daeken on freenode) or on AIM (bloomfilter).

Re: A full TCP/IP stack in under 200 LoC (and the power of DSLs)

#6
post #2

Downright impressive. I'm implementing the TCP/IP stack for my OS at the moment, and it's sitting at about 400 lines before TCP (ethernet, IP, DHCP, and ARP). Definitely going to see how I can improve it after this.

A friend of mine made millions selling his TCP/IP stacks since the mid 80s; he has written tens of them, all in various assembly languages.

Let me add that most of his work was for TCP/IP over serial ..

Re: A full TCP/IP stack in under 200 LoC (and the power of DSLs)

#7
The "meta-meta language-language" he mentions is OMeta. OMeta combines parsing and lexing and allows you to build your AST in your host language. It's really expressive and beats the pants off any other parsing framework I've used. The Viewpoints group is doing some of the most exciting work in CS right now, there's a lot of other interesting ideas they've been working on.

There are Python and Ruby implementations available. You can play with OMeta here: http://tinlizzie.org/ometa/

Re: A full TCP/IP stack in under 200 LoC (and the power of DSLs)

#8
Yes, TCP/IP is damned simple if you model it as a trivial lock-step protocol. And this is a slick little piece of code. But it has nothing whatsoever to do with the 10,000+ lines of code that modern operating systems deploy to allow hundreds of competing TCPs to figure out how to share a link.

Interview question: what's the important thing TCP provides over UDP?

Fail answer: I don't know.

Push answer: Reliability.

Win answer: Congestion control.

Re: A full TCP/IP stack in under 200 LoC (and the power of DSLs)

#9
post #5

Earlier quoted context omitted.

Hi Daeken, That's impressive. Are you writing your OS for study purposes or you have something special in mind? I am interested in knowing as I am planning to do the same and might want to consult you.

There's a post about the background and motivation for the OS (Renraku) here: http://daeken.com/renraku-future-os If you want to talk more about it or OS dev in general, feel free to ping me on IRC (Daeken on freenode) or on AIM (bloomfilter).

Are you doing this for fun or do you have something else in mind ? I'm curious :)

Re: A full TCP/IP stack in under 200 LoC (and the power of DSLs)

#10
post #8

Yes, TCP/IP is damned simple if you model it as a trivial lock-step protocol. And this is a slick little piece of code. But it has nothing whatsoever to do with the 10,000+ lines of code that modern operating systems deploy to allow hundreds of competing TCPs to figure out how to share a link. Interview question: what's the important thing TCP provides over UDP? Fail answer: I don't know. Push answer: Reliability. Wi…

Can you explain why there would be hundreds of competing TCPs?

I thought there were only a handful (Tahoe, Reno, Vegas, New Reno et al) of popular algorithms for the congestion control bit but it's all still TCP as specced in RFC 2581, no?

From where does all the complexity come?

Post reply on HN