Internet Backplane Protocol - Design, Details and Desire

Although still at the research stage, the IBP Service and Client API have been written, and working software produced, illustrating along the way some of the practicalities of producing such a system.

IBP storage takes place on servers called depots, which accept requests from remote servers and return results called capabilities. There are very few operations, as befits a model that emulates IP's deliberately simple range of functions: allocate, manage, store, load, two flavours of copy, and return status.

Allocate reserves and assigns an array of bytes on the depot, specifying how big the array is, how long it will survive and other attributes. The array is protected from third party interference by cryptographically secure passwords; after allocating, the manage function lets the client move pointers within the array, check what's going on or set some of its capabilities. Store and Load move data into and out of the array, and Status tells the client about the depot, and changes some of its parameters.

The design of IBP breaks down into four major areas, making the most of the advantages of an Internet model while minimising the weaknesses and limitations. As the basic function of any storage scheme is to move data around, special functions copy and mcopy have been created to move data from depot to depot. It is possible to do this through store and load through a client sucking data from one place and putting it in another, but efficiency and trust issues mean that it's far preferable to make a depot a temporary client capable of moving data under its own steam, on request. Copy does a basic data transfer over a TCP stream, while mcopy is more general. It provides a range of functions, from simple data transfer to real-time media streaming, and gives the client considerable control over what to do in the case of errors, how to optimally use the underlying infrastructure, and so on.

As anyone who's been on the Internet for longer than a day will realise, security is one of the biggest headaches, and storage is particularly unforgiving here. Capabilities are returned by the depot to the client in the form of long, cryptographically secure byte strings. These then form the basis of client request authentication: if the connection between the client and the depot is secure and the depot itself remains uncompromised, the presentation by the client of the secure byte string will authorise further actions. This is the only security feature IBP supports -- the security of the data itself is up to higher levels in the client. The depot is entirely agnostic about what's stored within it, and stores it transparently.

Another aspect of the basic unreliability of the IBP is its use of timeouts, which are used for different reasons in both client and server. In the client, timeouts ensure that if a request fails because the depot falls silent or communication is disrupted, control is returned and further action can be taken. In the server, the possibility of simultaneously issued reads and writes to the same area means that one may become dependent on the other; under such circumstances, it may be necessary to timeout an operation rather than hang around too long.

Finally, IBP includes ways for depots to refuse requests for a variety of reasons, and for clients to cope with such refusals. The allocation policy depends on a function of the space required by a client and the time for which it wants it -- the smaller the size or the shorter the time, the greater the likelihood that the allocation is fulfilled. This provides some defence against denial of service attacks; large depletions of storage will have short duration.

Other protocols that run atop IBP have been designed, most notably a single externalised data structure called an exNode. This aggregates multiple storage locations into a single network entity -- roughly the inverse of what a Unix inode does.

Prototype versions of IBP have been around since 1999, with version 1.0 released in March of 2001. Now at version 1.1.1, the code is available for Linux, Solaris, AIX, DEC and -- somewhat reluctantly, one feels -- Windows. There's also a Java client library, and copious documentation: everything is accessible at http://loci.cs.utk.edu/ibp/, together with pointers to some projects that are already using IBP.

The previous article Rupert Goodwins wrote on IBP is here.

Have your say instantly in the Tech Update forum.

Let the editors know what you think in the Mailroom.