Introduction

The belief that by the year 200x there will be more smart devices on the Internet than people has become widely accepted.  There are a number of TCP/IP high level protocols that have good potential for connecting smart devices, depending on the application and platform.  One of the most general (and complex) is the evolving series of transport and content protocols that are bundled under the banner of web service.  At its essence this is nothing more than an interface that transports XML documents using the HTTP protocol.  At this basic level a fairly general purpose server for information retrieval can be implemented in less than 500 lines of C (this represents approximately 3 KB of ROM in a M68HC12 micro-controller; download www.the-solution-llc.com/webservice.zip for all the technical details).  Use of the service can be easily incorporated into a web page (or other media) with just a small amount of scripting (VB or Java).  However, if we want our device to tie to the IT infrastructure or we want capabilities beyond just information retrieval, then we need to go further.  In the IT world we could use Web Servers extended with .NET or J2EE “middleware”.  For many smart devices, this is not an acceptable answer.  Not only are these components large, they are also maintenance intense.  So what would it take to make a fairly general purpose server that would meet our expanded requirements and still be embeddable?  This article will explore exactly that.

Requirements

The design of the reference implementations was driven by five primary requirements:

1. Load characteristics assumptions
   
2. The desire to support the general purpose application level communications required for remote command and control
   
3. The need to provide an interface that meets a “web service standard” likely to be acceptable for use by an IT organization
   
4. The desire to make an implementation that can be easily ported to modest platforms. This includes a small footprint and a very limited set of platform resource dependencies
   
5. The need to provide security that is sustainable on modest platforms

First, the design is driven by some load characteristic assumptions:

1. There is a relatively low level of traffic (on the order of a ten “messages” per second).
   
2. The device does not need to support a large number of simultaneous connections.

We want our interface to provide a very general purpose capability so that it will meet all our information retrieval, configuration and control needs.  The most general means of communications is to combine a command with a response, a conversation.  A message is the basic unit of communication to command an action or respond to a command.  At the minimum it is composed of a function code. Typical functions supported are:

1. START – start the indicated action.
2. STOP – stop the indicated action.
3. SET – set a parameter.
4. GET – get a parameter.

Additional message fields are required based on the nature of the message’s function.  A summary of a typical command and response message set is provided in the following table:

Command	Response
START,action	START,action,status
STOP,action	STOP,action,status
SET,parameter id,parameter modifier(optional),parameter value	SET,parameter id,status
GET parameter id,parameter modifier (optional)	GET,parameter id,parameter modifier (if present in command),status, parameter value

For the reference application we will limit ourselves to two actions, locking the device (i.e. preventing the modification of parameters or the execution of actions by anyone else) and “operating” and four parameters, all short (two bytes).

We need to meet “web service standards” at the interface (not necessarily internally).  This is a moving target, but there is a good practical starting point, the standards required by both the .NET and Java based tools that automate the construction of web service client stubs (this is pretty much the WS-I Basic Profile 1.0 without UDDI):

1. XML 1.0
2. XML Schema
3. HTTP 1.1
4. SOAP 1.1
5. WSDL 1.1

Since we control the definition of the web service, we will make some definition decisions that help to simplify our life (and appear to be the direction of the future gauging by the drafts of SOAP 1.2):

1. The XML will use the document style.
   
2. The encoding in the XML documents will be “literal” (i.e. they use XML Schema based definitions not SOAP).

The reference implementation’s dependency on platform provided resources was kept to:

1. A small sub-set of the standard C run time library that are available for most micro-controllers: memcmp, strcpy, strncpy, strcat, strncat, sprintf, strlen, strncmp and atoi.
   
2. A TCP/IP socket interface provided by either a software stack or by an Internet chip (iChip from One Connection).
   
3. Basic multi-tasking (threading) capabilities.

Finally, a “basic” level of security is assumed to be required.  The scheme used in the reference implementation is based on the concept of a one time pad and is suitable for even “deeply” embedded applications. The specific parameters used for the reference implementations follow:

1. The TCP/IP socket session will be the level at which access control is exercised.
   
2. Access security is provided by user authentication and different authorization levels matched to the command set (get data, set data, start/top actions).
   
3. At the beginning of each session the user must authenticate itself using a connection message.
   
4. The connection message has an encoded section which includes the OR of the user’s password and the current key. 
   
5. The response to the connection message includes the exclusive OR of the current key and the new key.  The new key is generated using a random number algorithm that has a good distribution and is suitable for use in generating cryptographic key material.