Internet Backplane Protocol - Design, Details and Desire
Published: 16 Apr 2002 17:44 BST
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.












