Slashdot Mirror
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."
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.
My preferred name is frazz, but someone keeps taking it. If you see him, tell him I said hi.
What about wireless? It's hard to get wifi hardware for microcontrollers, but easier for wired ethernet.
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.
EvilCON - Made Famous by
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?
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
a few kilobytes of memory and a few milliwatts of power budget - a thousandth of the resources of a typical PC computer
A thousandth? When was this article written, 1996? Try a millionth.
c++;
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.
I am TheRaven on Soylent News
I would have to say that the TCP/IP stack is a side show. The main feature is that it's an OS (or OS-like) that removes the burden of state machine implementation for protocol stacks. Each pseudo-thread is two bytes (one pointer) and it runs multiple processes. It also comes with a wireless sensor networking stack that can handle routing and mesh networking, a graphical toolkit for GUIs, and a library that's tailored towards memory-constrained protocol stack design. Did I mention you could also play Commodore 64 games with it?
Knowing how badly we've created SCADA environments (micro-controllers given [often internet facing] IPs and next to no security, I hope we do a better job with any medical implant devices. Many SCADA controllers will fail if you send them the wrong size ping.
I hope they add a lot more security to the medical ones, or better yet, don't give them any sort of connection with out something touching the individual. Maybe I'm a tad paranoid, but I'd hate to have a wireless IP monitoring my vitals. I can't imagine the havoc on someone's health you could cause by fooling their doctors to think they have diseases they don't. I would hope they are used for early warning only and anything they claim is verified by subsequent tests.
lol: You see no door there!
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.)
All hope abandon ye who enter here.
If it's supported on all that old iron, I don't see why there isn't a turnkey already in place for, say, something modern with equivalent horsepower. Say, for the mid-range PIC controllers.
I mean, if I am going to deploy this, it's going to be on hardware I can buy from Digi-Key, not the 'vintage' section on eBay.