Ideas for my occam IP implementation.
Pushing the boundaries
Commodity computer hardware is faster and cheaper than it has ever been, as always, but software has got slower and less reliable to match. I'd like to change that uwith RMoX: we should figure out the theoretical performance limits for the applications that we build, and then attempt to get as close as possible to them.
One example: software routing. There are existing systems that let you use a PC as a router, but they're generally considered to be too slow for production use. I'd be interested to find out how fast a software router should be able to go, and then see how close we can get to that using a future version of occamnet.
Pingable Lego bricks
At CSCS last week, Brad suggested a fun project: getting occamnet to run on the Lego occam system they'd built, so you could interact with a robot using IP. I suspect this'd be extremely difficult:
- the Transterpreter-based occam runtime doesn't do some of the occam-pi features like mobiles yet, which occamnet needs (although that'd be fixable)
- the RCX brick only has 32K of RAM, some of which is taken up by the runtime already
- the only network IO would be via the RCX towers; I don't know if they're flexible enough to do arbitrary bidirectional comms
A better approach might be to port one of the existing tiny IP stacks instead, and build an occamnet-lookalike interface to it.
It would be extremely cool to build robots that could communicate using Lego light bricks and light sensors -- they could flash Morse-code messages at each other! (Or even flash patterns that other robots of the same type could recognise...)
Bottleneck removal in occamnet
One of the possible advantages to using occamnet as a router would be that it could scale very well to multiple-CPU systems. However, occamnet at the moment has bottlenecks that prevent this, and I'd need to figure out how to remove them.
In many cases, this could be done by switching conventional channels for shared channels, and having multiple processes doing the same job (one per CPU). For instance, the IP checksum checker is such a bottleneck: there's no reason why you couldn't have multiple checkers runing in parallel sharing the same input and output, though, since you don't have to maintain IP packet ordering. (Although it may be desirable to do so -- I'd imagine some existing programs won't cope with out-of-order UDP very well, for instance...)
occamnet revamp
My third-year project was an IP stack for RMoX. In fact, I wrote it as a userspace process on Linux talking to the Linux IP stack using SLIP, and Fred later ported it to RMoX.
Obviously, it'd be useful to have a proper IP stack. occamnet as it currently stands has a few good features (I've done all the tedious stuff, like coming up with headers and writing code to do IP checksums properly) and a lot of bad ones (no TCP, at least one obscure bug in UDP, incomplete ICMP, dubious user API). Beating this into shape, and writing some network card drivers for RMoX so that it's actually useful, will be a useful project.
One of my specific plans is to make use of the new nested mobiles support to have a less clumsy representation of IP packets.
- Latest articles
- All articles (by name)
- All articles (by date)