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.

Re:Retarded headline

[DavidD_CA]

Agreed.

At first, I thought this got me hopeful that someone at the US Patent Office found a clue and that perhaps they might have landed back into our physical reality -- instead of the bizzaro universe they currently inhabit.

And then, after reading the first sentence from my RSS feed, I thought the story was about The Matrix being real. Or something like it.

Either way, I'm disappointed. And traffic in San Francisco still sucks.

Re:Retarded headline

[antifoidulus]

Considering that nowadays over half of slashdots stories are devoted to the pirate bay and whatnot, can you blame him? Whenever an ACTUAL tech article appears, its always a shock.

Re:Retarded headline

[teh moges]

Sounds more like a cleverly disguised advertisement to me.

Re:Retarded headline

[pjt33]

You had me until "cleverly disguised". Since about 90% of stories on /. nowadays are advertising, it's less a question of cleverly disguising it and more a question of hiding a tree in a forest.

Re:Retarded headline

[cryptodan]

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.

Isn't the hardware that allows the Internet Protocol to exist the true "Physical Reality". Because without layer 1 you have no way to transmit.

Cyberpace daemons!

[Anonymous Coward]

oh shit, if cyberspace and reality merge then it will allow the cyberspace daemons to cross over in to our world!

The end is here!

Re:Cyberpace daemons!

[Tangent128]

Look on the bright side- you can surround your house with a firewall and have a barbecue! Just like in the movies!

Plus all those retailers giving you free cookies...

Re:Cyberpace daemons!

[__aadhrk6380]

If cyberspace and reality meet, millions of geeks worldwide will finally meet their cyber-girlfriends and actually consumate their relationships. Floods of ugly, highly intelligent children to follow.

Wait a minute, my bad. I think that is what the OP was getting at...

Re:Cyberpace daemons!

[lordofwhee]

Replace security guards with UNIX admins, TV with Apache, talking with perl...

Sounds like the kind of place I'd like to live.

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

[Anonymous Coward]

Why do they use TCP/IP then. Wouldn't it be better to use some more advanced/efficient network stack. The AP can then gateway with TCP/IP. They probably will speak IPv4 instead of IPv6 anyhow.

I see the point in using TCP/IP for the internet as it is a standard but not on the edge for networking specialize devices.

Does anybody know?

Re:Ubiquitous Computing

[mpeg4codec]

What you're talking about is called Mobile IP, which is standardized by RFC 3344. Doesn't seem to be used very widely, probably because the density of 802.11 access points isn't high enough for it to be useful in most areas.

Re:Ubiquitous Computing

[jd]

That's one form of Mobile IP, there appears to be some work on passing upstream routing optimizations so that the connection eventually switches from relayed to direct, presumably providing there is something that can act as a new home base in the new location. You're right, Mobile IP isn't much used, but I'll blame that less on the infrastructure and more on the lack of support or documentation in such systems as Windows, which - like it or not - determines what the hardware vendors care about. Bleagh.

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.

Re:Ubiquitous Computing

[Anonymous Coward]

openvpn ftw

Re:Ubiquitous Computing

[jd]

If badly-functioning financial institutions can be taken over by the Government, maybe it should be law that badly-functioning ISPs should be taken over by Slashdot readers. We can't do worse with technology than the Government does with money, and at least things like Mobile IP and NEMO (Network Mobility) might gain some visibility.

Re:Ubiquitous Computing

[navinprakash]

QROPS

Re:Ubiquitous Computing

[navinprakash]

Expat Spain

Re:Ubiquitous Computing

[tlhIngan]

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.

MobileIP may not be used much on the live Internet, but it's certainly very popular and used by a number of people (though they often get ravaged on fees for the privilege, like that $19k phone bill). Yes, the cellular network uses it, not for intra-carrier packet routing (the cell network already handles handoffs and such within a carrier), but for inter-carrier packet routing (i.e., roaming data). This is because you may have a data session in progress, and all of a sudden, move into a roaming cell. It would be quite annoying if one's IP session was reset because of the switch (and thus having to get a new IP, etc. etc. etc), so they use MobileIP to ensure that existing connections aren't reset.

This also happens if you're roaming and establish a data connection - your packets are sent back to your home carrier for transmission to the Internet.

Which makes it possible for carriers to figure out how much traffic you're using and how much is roaming, and thus being able to warn you before the bill arrives.

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.

Re:Also runs on C64

[that this is not und]

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.

Re:Also runs on C64

[LWATCDR]

You should read more than the wikipedia.
"Contiki runs on a variety of platform ranging from embedded microcontrollers such as the MSP430 and the AVR to old homecomputers. Code footprint is on the order of kilobytes and memory usage can be configured to be as low as tens of bytes."

And running on a C64 isn't such a bad thing. You can get a C64 that fits on a FPGA. If you want a low end computer that will drive an NTSC monitor you could do worse than a C64.
http://www.syntiac.com/fpga64.html
Maybe there is a market for a single chip C64 with some flash, ethernet, and Contiki.

Wireless tech

[Anonymous Coward]

What about wireless? It's hard to get wifi hardware for microcontrollers, but easier for wired ethernet.

Thanks Timothy

[oodaloop]

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

Re:Thanks Timothy

[felipekk]

Stop nitpicking. The article is about the operating system and the summary clearly states that.

Re:Thanks Timothy

[TheRaven64]

The story is about Contiki. It's a very shiny OS, with IPv4 support and a lot of other nice features in only 64KB of RAM (including space for a few userspace apps). It was originally developed for sensor networks, but got ported to the C64 and quite a few other machines. There are also a load of completely irrelevant links.

Re:Thanks Timothy

[Oktober Sunset]

It's a clever ploy to make you read the article.

Re:Thanks Timothy

[oodaloop]

Well, it didn't work. I'm too smart for that.

better headline

[QuantumG]

"IP Addressing of Every Little Thing"

and yes, it's boring.

Imagine a beowulf cluster of these babies

[davidwr]

Ok forget the beowulf part.

Imagine a networked swarm of these babies.

What Does This Have to Do with Google?

[Comatose51]

What does any of these have to do with Google? Contiki sounds like an awesome embedded OS for things like wireless sensor networks. Wireless sensor networks often use TCP/IP (or variations of, such as IwIP used in Contiki: http://en.wikipedia.org/wiki/LwIP) for their networking. The link between Contiki and Google would be Contiki -> TCP/IP -> Internet -> Google, therefore Slashdot worthy?

Seriously, not everything has to do with Google in order for it to be "News for Nerds". Being able to do so much with an OS within such limitations is very impressive and has merits of its own.

Re:What Does This Have to Do with Google?

[MichaelSmith]

Seriously, not everything has to do with Google

I know but tell that to my Sister in law. I got this call from her this morning because google had disappeared from her laptop. It turned out that she had at some point installed Safari, possibly because she runs iTunes. Then something happened and the home page of safari got set to apple or something and she lost her only ability to find things on the internet. I said okay lets start firefox and she said firefox? is that the same as google?

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.

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.

Re:I hope they're using IPV6

[TheRaven64]

No, it uses uIP, a tiny IPv4 stack. Fitting an IPv6 stack into a machine with 64KB of RAM is nontrivial. uIP requires about 4KB of RAM to hold the code and then around a hundred bytes for each connection.

Of course, there's no reason why they can't have public v6 addresses, if you run them all in 10/8 and the gateway maps each address in this range to a separate v6 address and handles the protocol translation.

Re:I hope they're using IPV6

[pbrandao]

There's an IETF group working on IPv6 over Low Power devices: 6LowPan (with RFC4944 already released). From what I know they are using header compression and adaptation to the normal IPv6 header to be able to use it over 802.15.4 (this is the "entry" MAC protocol, future objective is to be transparent to lower layers). A routing protocol is also under development in coordination with 6LowPan, the Routing Over Low power and Lossy networks (roll).

Don't know the status of Contiki regarding this.

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.

Re:ubiquitous IP

[itsthebin]

wireless IP cameras are already here

I've even used Wifi cameras connected to 54GL APs with tomato setup as AP+WDS , so only 1 cat6 from 1 AP back to the main switch.

these cameras are running embedded linux at the moment , streaming D1 MPEG4 - will be switching to eCos http://ecos.sourceware.org/about.html soon.

won't be long before the cameras will all be connected to each other with WDS ( Wireless Distribution System ) with STP ( spanning Tree Protocol ) to stop broadcast storms.

To those saying "why?"

[Anonymous Coward]

Alternate Title:

Internet Zero

http://www.mywiseowl.com/articles/Internet-0
http://cba.mit.edu/projects/I0/

Cool to see there's an OS targeting this concept directly now.

I think its time..

[plasmacutter]

I think it's time to frame the lincoln tunnel for copyright infringement.

Um...

[Anonymous Coward]

Hyperbolize much?

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.

A thousandth?

[pipatron]

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.

Look at the code - it is IPv6

[Anonymous Coward]

I am not as well-versed in this as you seem to be, but from looking at the code, there seems to be both IPv4 and IPv6 in there. IPv6 is enabled by a C preprocessor switch (UIP_CONF_IPV6):

http://contiki.cvs.sourceforge.net/contiki/contiki-2.x/core/net/uip.c?view=markup

Thought this was already done.

[sethstorm]

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.

Wouldn't this have been covered by Airespace/Cisco? Unless they just do autoconnect, I'd be sure that they do something like that.

No great feat

[ThePhilips]

My friend to demo his diploma work implemented trivial TCP/IP & HTTP for micro-controller with only 2K flash memory and 2K of RAM. Main work was specialized signal processing - monitoring over HTTP in HTML (with some bits of JavaScript) was pure bonus.

TCP/IP itself when implemented for only particular tasks is not that complicated. Modern OSs has to accommodate all possible applications and scenarios (including security stuff) and TCP/IP ends-up being quite bloated.

Re:No great feat

[Anonymous Coward]

Just because your friends trivial TCP/IP stack was no great feat, doesn't mean that this isn't. If you read up on it, the TCP/IP stack mentioned here seems quite a bit more elaborate than a simple diploma demo. From the PDF:

"We describe two small and portable TCP/IP implementations fulfilling the subset of RFC1122 requirements needed for full host-to-host interoperability. Our TCP/IP implementations do not sacrifice any of TCP's mechanisms such as urgent data or congestion control. They support IP fragment reassembly and the number of multiple simultaneous connections is limited only by the available RAM. Despite being small and simple, our implementations do not require their peers to have complex, full-size stacks, but can communicate with peers running a similarly light-weight stack. The code size is on the order of 10 kilobytes and RAM usage can be configured to be as low as a few hundred bytes."

So this is a compliant stack in 10k code. Quite a feat, if you ask me.

Re: No great feat

[freaklabs]

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?

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

Re:No great feat

[ThePhilips]

BTW, forgot to mention another big variable affecting size of TCP implementation.

Do you need to support BSD socket API or not?

The BSD sockets provide quite number of services, supporting which is quite elaborate. e.g. accepting connection with system call vs. notifying application asynchronously that it has a new connection. or the same applied to received packets. or synchronous sending.

TCP in 10k without BSD sockets interface is doable and not complicated.

Re:No great feat

[Anonymous Coward]

The PDF linked above is actually about lwIP (which was originally written by the Contiki author, btw).

It is a shame.

[www.sorehands.com]

It is a shame that people think that getting something to fit into 64k of ram is a big deal. I remember spending over $100 to upgrade my Apple ][+ clone from 48k 60 64k.

Much of the code today is poorly written and wasteful of memory.

Re:It is a shame.

[ColdWetDog]

It is a shame that people think that getting something to fit into 64k of ram is a big deal. I remember spending over $100 to upgrade my Apple ][+ clone from 48k 60 64k.
Much of the code today is poorly written and wasteful of memory.

Right. Of course, you were running 1900 x 1200 x millions of colors on that old Apple ][ monitor weren't you? And connecting at 1 Mbs? And downloading YouTube?

Hell, at best you were downloading ASCII porn.

Back to the Dungeons of Yesteryear for you!

Re:It is a shame.

[cryptodan]

It is a shame that people think that getting something to fit into 64k of ram.

So I guess Bill Gates was right then, all you need is 640K.

Sorry - this news was beaten nearly a decade by...

[teknopurge]

Sun.

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

Java, ftw.

You can by SunSPOT dev kits for a few hundred bucks. People have already build p2p networks with them. Exciting enough to remind us of the old XeroxPARC days.

Lets get it right this time...

[g0dsp33d]

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.

The SunSPOT is much newer

[Anonymous Coward]

The SunSPOT is not a decade old, it is much newer. And it is built around a much heftier CPU (an ARM with megabytes of RAM, IIRC) so they would cost much more than the low-cost devices discussed in TFA.

Re:The SunSPOT is much newer

[teknopurge]

I did say -nearly-, i think it was late 02 that the project was released, so development was at least several months prior.

As for cost, it's all economies of scale. You can get SPOTs cheaper in bulk, though you are correct, the SPOTs do a much broader array of things.

Re:The SunSPOT is much newer

[Anonymous Coward]

No matter how you turn it, with hardware with a higher cost, your final system will have a higher cost. (Assuming that the number of devices is fixed of course.)

But Java runs on small, low-cost devices, there is no need to use the heavy-wieght SunSpots. Just go to Sentilla: http://www.sentilla.com

Shades of Vinge's Localizers?

[corso64]

Did anyone else think of Vernor Vinge's Localizers after reading this? -- "Reality is that which, when you stop believing in it, doesn't go away." -PKD