Device connectivity: a whole new set of secret handshakes

Getting our myriad devices-from PDAs to PCs-to communicate requires a common language and protocol. Several candidates for the job have very different ways of determining who

By Nicholas Cravotta, Technical Editor -- EDN, 1/6/2000

For device connectivity to have any chance of success, devices must be able transparently and with guaranteed success to exchange services. The physical medium and protocol over which devices can communicate include many mature and proved technologies.

Some of the more prominent pipes include phone lines via modems or Home Phone Networking Alliance lines; wire via Universal Serial Bus, 1394, serial, and parallel wires; power line; and wireless via Bluetooth, Infrared Data Association (IrDA), and HomeRF methods. The connectivity challenge lies in deciding how to exchange services once you establish a connection. Technologies such as Jini, Universal Plug and Play (UPnP), Salutation, and JetSend promise to meet this challenge by addressing the NXN device-driver problem.The standard connectivity model requires a total of NXN drivers to support the varying combination of devices and service providers (Figure 1). In the traditional world of the PC network, the "consuming" device uses a service, often the PC itself. This device must have a driver to tell the service provider—a printer, for example—how to work at a physical level; that is, how to send data to the printer to print lines, text, or images. This driver establishes the connection (over a parallel port, for example), defines the available functions, and manages the use of the service.

Jini, the connectivity technology that Sun supports and drives, is a Java-code construct/protocol to establish an exchange of services. Apparently, you can use Jini without using Java, but such a course seems contrary to the intended model. The key feature of Java, portability of code across diverse platforms, reduces the NXN-driver problem to N drivers, because the driver for a printer, for example, runs on any appropriate Jini-enabled device.

The concept behind Jini is that a device dynamically locates services, downloads them for use, and then discards them when they are no longer necessary. For example, Jini would negotiate between your personal digital assistant (PDA) and your printer to allow you to print a document. Note that Jini does not download the services themselves, but rather it downloads an interface through which a device can interact with the services.

Jini does not currently support peer-to-peer, two-node connections but requires at least three nodes: the service consumer (your PDA); the service provider (a printer); and the Jini look-up service, a meeting place for services. When service providers join the network, they register the services they offer through the use of Java objects. A printer, for example, would register that it prints in black and white and color and on oversized paper. To print a text document, the PDA would select the black-and-white service from the options registered and download the appropriate Java interface. Note that interfaces are not limited to devices such as printers; an interface could also describe how to use a banking service. In this context, every application can be a service.

Jini interface-driver developers base the drivers on predefined device profiles. For example, a Jini printer profile guarantees support of certain functions. If a PDA wants a function, such as printing in color, it can try to locate an appropriate subprofile offering that function. If such a service is unavailable, the PDA can step back through the profile until it finds a lower level of service. The look-up service then downloads an interface that allows the PDA to interact with the printer, reflecting whether color, page size, and other variables are available.

The classification of services is a cornerstone of Jini. The Jini special-interest group defines each device profile to support specific services so that a device knows its appropriate function. One disadvantage of defined classes is the difficulty of extending functions. For example, if a Jini cell phone does not support video, and you develop a phone that supports video, you technically don't have a cell phone. Profiles for PDAs, set-top boxes, cell phones, and others are still under development.

Jini is free under certain conditions for educational and internal use. Under a commercial-use license, you are subject to a 10-cent fee per unit shipped or an annual subscription fee of $250,000 for each product. Through the Sun Community Source License (SCSL), Sun shares the rights to the source code among the Jini community of developers to enhance and evolve Jini technology.

The developers of UPnP, another of the foremost connectivity technologies, based it on Microsoft's PC Plug and Play model, the chief difference being that the UPnP allows peer-to-peer connections without requiring that a PC referee the exchange (or bear the processing load of managing all of the various drivers). UPnP uses open Web-based standards, such as Transmission Control Protocol/Internet Protocol (TCP/IP), Hypertext Transfer Protocol, and Extensible Markup Language (XML) with device-control protocols (DCPs), similar to Jini profiles. When a device connects to other devices, it initiates simple service discovery, announcing via multicast its presence, its function, and its address (uniform resource locator, for example). For example, a PDA might announce that it is a PDA and that it would like to print. An appropriate printer would respond.

The first UPnP Forum meeting took place in June 1999. The forum is an open industry initiative with Microsoft as a member. It has no distinct timetable but hopes to have general products available by late this year. The initial efforts will form a steering committee and begin to define the DCPs. Many companies are on both the UPnP and Jini committees and are trying to create the same kind of device hierarchy. Although UPnP could universally reduce the complexity of device-driver development, the number of drivers required is still NXN, given that not all PDAs run Windows CE on an x86 platform.

Another available connectivity technology comes from the Salutation Consortium, which has been in place in office-automation markets for several years. It has defined functional units, similar to Jini profiles, for printing, faxing, scanning, telephony, scheduling, and address books, and work is under way for display and operating environments. At press time, a "light" version of Salutation should be available for Windows CE. This version requires only 18 kbytes to support service discovery and management (begin job, end job, and status), and the consortium has scheduled PalmOS and Java versions for later release. A software product called Port of Entry enables desktops without Salutation to interact with Salutation devices.

Salutation offers peer-to-peer connectivity. Drivers focus on the operating system; a printer needs to store drivers for itself for Windows, PalmOS, Windows CE, Mac, and so on. For peer-to-network connectivity, an information server asks a device for a self-description, including display, OS, processor, and so on. The information server can then download information appropriate for the type of device; that is, to send the small or large, black-and-white or color graphic.

One differentiator of Salutation is the use of binary streams versus the text streams typical of XML. This feature yields benefits in low-bandwidth environments, such as wireless connections. Salutation also supports extensions through the use of a vendor escape, allowing vendors to add support for unique features. No open class for such extensions exists, but the Salutation group recognizes the need for one. Salutation is independent of the protocol and pipe, employs an open-source model similar to the Linux model, and is free to use.

JetSend

Another key connectivity option is Hewlett-Packard's JetSend. JetSend differs from the other three standards in that it includes no service discovery. Instead, it defines a language for devices to share information and assumes that a bidirectional connection already exists. JetSend now supports TCP/IP and IrDA. JetSend complements UPnP, Jini, and Salutation in that it provides a language for devices to talk to each other once they discover each other. HP released JetSend in 1997, and 5 million JetSend-enabled devices, mostly printers, are on the market.

JetSend's greatest strength lies in addressing the NXN problem. Typically, for a PDA to talk to a printer, the printer must supply drivers for each platform based on OS, processor, and the unique features of the individual printer. JetSend reduces the challenge of supporting variation by shifting the decision of what to do with data from the consuming device to the service provider. Instead of devices trying to understand each other's functions, the consuming device sends the data it wants to send, not caring how the service provider decides to consume the data. E-mail gateways consume data by sending it to the network, printers consume data by printing, and so on. For example, a camera can provide an image as a JPEG file, a 24-bit color file, or as gray or monochrome data. The camera declares that it has information and that it can offer it in these various encodings. The printer then picks the encoding it wants to print; a black-and-white printer would choose monochrome; a color printer would choose the 24-bit color file; and so on. Thus, the number of drivers necessary depends on the data formats supported. Note that this approach reduces processing overhead on consuming devices because they need not support the extra processing and memory that supporting multiple drivers entails.

Another example illustrates the power of this reversed interaction. When two PDAs exchange contact information, the sending device can tell the other device that it has text; a virtual business card (vcard) or an image for devices, such as printers, that don't understand text. The receiving PDA could then select the vcard and directly add it to a contact database.

JetSend comes as C source code and in full-blown-, PDA-, and midrange-stack sizes. JetSend supports extensions to data formats through either HP, adding them to the standard list, or through defining a unique company tag to flag proprietary information. Last November, HP announced JetSend for Windows CE, an off-the-shelf product introduced at $9.95. It allows CE devices to connect to other CE devices over established connections, such as infrared. During the first quarter of this year, you will see a PalmOS version. On the OEM side, Version 3.0 of the JetSend development kit is available. The kit has a free, 60-day-evaluation license and includes source code, tools, and sample code. A one-time fee of $25,000 covers all products released across a company.

System issues

These connectivity standards are the beginning of an attempt to transparently connect devices. Which one is best? The answer doesn't matter; it matters more whether any of them can achieve pervasiveness among consumer devices. Service providers, such as you might find at an airport, will probably end up supporting all of them if they want to maximize revenue streams. A better question is: What is the best means of bridging the various standards and established networks to prevent a standards war that will only delay widespread deployment of device connectivity?

The work so far has hardly solved the overall connectivity problem as issues arise that either the standards must define or the users of each technology must decide how to manage. For example, you need a mechanism for handling duplicate services, such as two printers. Also, when you load drivers into a device, you may change the settings for an old driver. And, no method exists for managing an errant device that brings down the network by letting everyone know the services it has available 1 million times/sec. Extensions for new services is a critical issue that must respect that OEMs do not necessarily want to expose such services to competitors before product release. Robust security is another key issue, especially if services require electronic fees.

The foundation for connectivity is coming into place. However, much real-world work remains to ensure that such conversations are polite and productive.

Author info