TCP/IP Meets Physical Reality

An anonymous reader writes "When Google is clouding the borderline between web and the desktop, a much, much smaller project is blurring the border between the Internet and the physical reality: the newly released Contiki operating system version 2.2.1. Contiki runs on networked wireless sensors that are used for anything from road tunnel monitoring for fire rescue operations to collecting vital statistics from ice hockey players. These sensors typically have as little as a few kilobytes of memory and a few milliwatts of power budget — a thousandth of the resources of a typical PC computer — yet Contiki provides them with full TCP/IP connectivity. Meanwhile, San Francisco is monitoring parking spaces with wireless technology."

Comments

Retarded headline

[QuantumG]

No only did I think the story was about Intellectual Property, it also makes no sense at all. The Internet Protocol has been a "Physical Reality" for decades.

Re:Retarded headline

[psycho sparky]

That's the lawyer in you, not the geek.

Re:Retarded headline

[dafrazzman]

What is the point of this story, anyway? It seems to be about Contiki, but it ends with something on parking meters? How is clouding relevant?

What does "Internet Protocol Meets Physical Reality" mean? Wireless interfaces in everyday applications have been around for years. Forget headlines, this whole story seems to be pointless.

Ubiquitous Computing

[The Master Control P]

This is one of three parts that will enable ubiquitous computing - the ubiquitous data gatherers & environmental sensors.

The second is a wireless routing protocol that really supports jumping from one AP to another (This will be worked out, probably as a derivative of cell phone networks, when people start roaming further than a single WiFi AP and demand seamless transitions) without disrupting existing sessions. More than just auto-connecting to a new AP, but having previous datastreams (streaming music, calls, chat) redirected to the new address and handing over authentication tokens as well.

The third is a system capable of generating or pattern-matching meaningful information from new sensors without being explicitly told how (since not even a geek such as I would want to program my implants to recognize every new blobject they encounter). We'll get there eventually.

Re:Ubiquitous Computing

[Comatose51]

I read a paper when I was in college that takes care of the 2nd problem. Basically you have a home station that is always aware of where you are. When you're at your home network, everything is fine. When you move into another network, you inform your home station of your new location. Everytime you send out a packet, you continue using your home station as the "reply-to" address. As far as everyone else is concerned, you haven't moved at all. When your home station receives the packet destined for you, it forwards it to your current network, which then hands it off to you. Not exactly the most efficient protocol in the world but it gets the job done.

Re:Ubiquitous Computing

[TheRaven64]

The second is a wireless routing protocol that really supports jumping from one AP to another (This will be worked out, probably as a derivative of cell phone networks, when people start roaming further than a single WiFi AP and demand seamless transitions) without disrupting existing sessions

This has been in the 802.11 family for some years, but had a jitter too high for VoIP applications. A new version was published last week which permits seamless transitions between WAPs fast enough that even VoIP users don't notice it.

Re:Ubiquitous Computing

[stevedcc]

You're talking about two different things, really. I work for a company making sensor network software and hardware. You're never going to get it running on the same Access Pointss as consumer internet - the requirements are too different.

For the sensor networks, we're aiming for 10 year battery life, with network bandwidth that makes modems from 10 years ago look fast. No one wants to use that for their AP.

The ONLY part of the sensor network that might use a consumer AP is the link between the sensor net and the outside world - but in practice sticking a SIM card into the link is the easiest thing

Re:Ubiquitous Computing

[DrStrangeLoop]

briefly, the reason you don't see MobileIP deployed is because MobileIPv4 requires a Foreign Agent in the foreign network, ie in the network where your Mobile Node is right now. as there's no clear incentive to the foreign networks administrator to provide such a thing for you, it seems unlikely that this will become commonplace. MobileIPv6 however does not require a Foreign Agent, as long as your Mobile Node and the Correspondent Node (ie the server you want to talk to) both speak IPv6, the only other thing which is needed is a Home Agent in your own network, which you can set up at your own leisure.

Also runs on C64

[Saffaya]

Looking at the wikipedia page :

http://en.wikipedia.org/wiki/Contiki

Confirms why I thought of the C64 when I read Contiki.
Here is a list of supported systems from wikipedia :

        * Computers:
                    o Apple II family[1]
                    o Atari 8-bit[1]
                    o Atari ST
                    o Atari Portfolio
                    o Casio Pocketview
                    o Commodore PET[1]
                    o Commodore VIC 20[1]
                    o Commodore 64[1]
                    o Commodore 128[1]
                    o GP32
                    o Oric
                    o PC-6001
                    o Sharp Wizard
                    o x86-based Unix-like systems, on top of GTK+ as well as directly using the X Window System[2]
        * Video game consoles:
                    o PC Engine
                    o Sega Dreamcast
                    o Sony PlayStation

        * Handheld game consoles:
                    o Nintendo Game Boy
                    o Nintendo Game Boy Advance

Impressive features as well :

A full installation of Contiki includes the following features:

        * Multitasking kernel
        * Optional per-application pre-emptive multithreading
        * Protothreads
        * TCP/IP networking
        * Windowing system and GUI
        * Networked remote display using Virtual Network Computing
        * A web browser (claimed to be the world's smallest)
        * Personal web server
        * Simple telnet client
        * Screensaver

Re:Also runs on C64

[MichaelSmith]

Sounds great for the openmoko.

Thanks Timothy

[oodaloop]

Another brilliant, clear, and useful article summary about...what exactly? The connecting-things-to-stuff dept doesn't help much either.

I hope they're using IPV6

[darkonc]

all of the units in a single project could easily fit into a single 48-bit user space, but if you start trying to give individual sensors unique IP4 addresses, you're going to chew through the IP address space in short order.

If, on the other hand, you try to use private IP4 address blocks, you're going to risk address collisions when you try to combine networks (and have a harder time resolving such collisions, given the kind of objects you're playing with).

Re:I hope they're using IPV6

[dtmos]

See 6LoWPAN. Or here.

ubiquitous IP

[TheSHAD0W]

Met a friend at a property I'm renovating, and gave him an old time-lapse VCR and video switching unit to play with. We were talking about how the technology's changed.

Ten years ago, even five years ago, you'd get an expensive VHS-based VCR with a time-lapse mode, and an expensive video switching unit that would alternate individual frames of video to send to the VCR, and to separate the playback.

Now, you buy a DVR with multiple inputs - or a full-fledged computer with a PCI card that lets you hook multiple video inputs into it.

Five years from now, it'll be a computer with a simple gigabit ethernet interface, plugged into a 802.11n+ wireless router, and the cameras will all send their video streams over the air, no analog wiring at all.

Ain't technology grand?

Re:ubiquitous IP

[flonker]

Security cameras transmitting over the air is a bad idea. Jamming radio is old news and quite easy to do.

Using Contiki on my open source Zigbee project

[freaklabs]

Currently, there are two popular "OSes" being used for wireless sensor networks. One of them is TinyOS and one of them is Contiki. The challenge is that WSN nodes are usually battery operated, small, and need to last for a very long time. That means that you're memory restricted and power restricted which are difficult limitations for OS developers. I prefer using Contiki on my open source Zigbee project because its developed in ANSI C, unlike TinyOS which requires a variant of C called NesC. I'm also using a lot of libraries from Contiki which is keeping the protocol stack size down. I'm probably around 30-40 kB right now which is already big by WSN standards. FYI, the Contiki uIP protocol stack is about 20kB including the OS. The Contiki OS alone is about 2.5 kB, and some people have gotten TCP/IP on it running with 250 bytes of RAM. Not sure how they pulled it off. Contiki is really an amazing OS. For those interested in checking out my project, in can be found here: http://www.freaklabs.org/ Akiba

Re:Using Contiki on my open source Zigbee project

[TheRaven64]

The Contiki OS alone is about 2.5 kB, and some people have gotten TCP/IP on it running with 250 bytes of RAM

250 bytes of RAM is enough for uIP if you can have the code in ROM. It limits you to around one or two connections, but I'd imagine a device with only 250B of RAM doesn't have enough resources to handle more than this anyway. All of the RAM used by uIP is statically allocated, so compiling it with support for just 1 connection will get it down to a footprint of around this size. I'm not sure if the 250B figure was for just the IP stack or for the OS, IP stack and application. If it's for everything, then that's indeed quite a feat. If not, then it's relatively easy. You can trim the RAM usage for uIP down really low. One of the biggest RAM users is fragment reassembly. If you use UDP only and restrict yourself to packets smaller than the MTU (it's pretty hard to have bigger ones with only 250B of RAM anyway...) then you can make it very small. Using the zero-copy API, almost all of the RAM you need is the send buffer.

Re:What Does This Have to Do with Google?

[TheRaven64]

LwIP is an IP stack (not a variation of TCP/IP) written by the author of Contiki, however it is not used by Contiki. The uIP stack, written by the same author, is used by Contiki.

Re:No great feat

[ThePhilips]

From my experience, biggest challenges in TCP are the all other smaller RFCs written after TCP became STD.

If you look at other projects e.g. LWIP, you will notice that core TCP code isn't that large. Many parts deal with compatibility issues, with security issues and of course with memory management. (Many disregard memory management, yet TCP for effective work has to have quite an amount of memory: otherwise bandwidth would be quite limited.)

From my personal experience, TCP is nothing more than ring buffer, four counters and FSM to track the counters. Rest is optional and can be easily simulated, remaining within RFC requirements. (Yes, I was implementing TCP long time ago for traffic shaping module.)