Remember when typing http:// seemed novel and exciting? Now get ready for nabto://. The putative “network access bridge to” protocol may be the latest thing to hit embedded devices.

Developed and promoted by a small Danish company called Nabto, coincidentally enough, the Nabto protocol is a way for small and stupid embedded devices to serve up a rich diet of HTTP content on a starving programmer’s budget. Nabto (the company) says Nabto (the protocol) can serve full Web-style HTML, graphics, style sheets, Javascript, and so forth using just an 8-bit microcontroller with less than 1K of memory.

The idea is to allow low-cost embedded devices to communicate over a LAN, WAN, or the Internet with almost no overhead. Devices can use Nabto to deliver a good-looking user interface to a standard browser, something many home/office routers do now. By reducing the cost and resource requirements for an embedded HTML server, Nabto hopes to make such browser interfaces nearly ubiquitous. Why add pushbuttons and LEDs, or develop GUI firmware, when you can rely on the user’s browser?

As a nice side effect, Nabto says its embedded network protocol works through firewalls, an important feature as most low-cost embedded devices are behind the home or office firewall. In the same way that VoIP clients make firewalls invisible to the average user, Nabto simply assigns each embedded device its own “phone number” and handles the IP-address resolution behind the scenes.

How do you get a full HTML Web server into 1K of memory? You cheat, that’s how. Nabto’s protocol relies on the cooperation of a third party to store and, when requested, forward the bulk of the HTML, graphics, and scripts. The embedded device itself stores almost nothing, and the client browser, of course, has no idea what content to expect. Nabto enlists a third server somewhere on the LAN, WAN, or “in the cloud” to serve up the bulk of the content based on short tokens or codes delivered by the embedded server. This three-way cooperation cuts way back on the storage requirements of the embedded device itself while still allowing it to serve – or appear to serve – feature-rich content.

This all assumes, of course, that there’s a third resource available on the network. But that’s not a tough sell in most networks. The “third” resource can even be the client PC loaded with device-specific content. For example, a simple Nabto-enabled thermostat might communicate with a browser on a client’s PC after the owner has installed a CD of thermostat-specific software.

Or the bulk of the content can be stored on the thermostat manufacturer’s publicly accessible Web server, available to any Nabto client request. Either way, the user sees full HTML Web pages served up by a thermostat with almost no storage and very little processing power.

Networks, by their nature, tend to have a lot of devices connected, and finding one with a few extra kilobytes for storage and few extra MIPS for fielding Nabto requests isn’t a big burden. And there’s always the Internet and its infinite resources. In exchange for piggybacking on the resources of a third participant, the Nabto-enabled device gets to provide Web services with very little overhead. It’s a different form of client/server symbiosis.

Now the Internet-enabled Coke machine costs less than the Coke.