Ah, damn. A USB stick. I was really hoping the train would be carrying actual SYNs, ACKs and DATA payloads using differently colored bricks :)

The wonderful thing about nerd rage is that it gets stupid things done. I fully expect to see a response project of ACTUAL TCP/IP implementations via lego trains. Hell, multiple response projects, probably.

And then someone will do IPX/SPX just to be cute.

> I fully expect to see a response project of ACTUAL TCP/IP implementations via lego trains.

Here's hoping that they also work their way up the OSI stack. I'm looking forward to seeing what "418 I'm a teapot" looks like from the LEGO http server.

or even a full x.400 mail system linking to a real x.500 directory

Yeah, it would be interesting to see this handle all of the different requests.

I would had called the post "TCP/IP on Rails"

The article doesn't do much to explain how it uses TCP/IP which makes me wonder if it does at all?

So, token ring networking with a data-carrying physical token. Neat.

It would be neater if it were a freight train carrying blocks for bits. Using a USB key isn't really 'Lego' enough.

The trick would be loading/unloading the cars in a reliable and fast way. With a multi-cart train running in a loop, I probably wouldn't shoot for TCP/IP.

Something like T1 would be a lot easier to implement because it uses very straight forward time-division-mutiplexing (serial by nature). You could use a simplistic encoding method like AMI, but your frames would have to be much smaller. The simplest T1 carrier frame is 192 data bits with 1 signaling bit, so you're looking at a pretty massive train. Because the physical train itself could serve as the frame boundaries, you could use 16 cars and carry two bytes per trip.

The bit rate and latency are going to suck though ;)

it reminds me of IP over Avian Carriers: http://en.wikipedia.org/wiki/IP_over_Avian_Carriers

You mean one of the humorous RFCs that the article refers to and links to already, right?