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

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.

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.

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: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: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.)