XIO: Key Concepts

Overview

Globus XIO is an extensible input/output library for the Globus Toolkit (tm) that provides a simple and intuitive API (open/close/read/write) to swappable IO implementations.

Globus XIO has 2 main goals:

  • Provide a single user API to all Grid IO Protocols.

    In Distributed programming there are many protocols used for message passing. There are typically many different APIs for using all the different protocols, despite the fact that they have the same end goal, moving bytes from end point to end point. Application developers are forced to code straight to a protocols API. Therefore if they ever want to change the underlying protocol they originally selected, then they have to change the applications source code to utilize an entirely new API. Even subtle differences in the API can become a difficult task. This adds to the already complicated task of keeping up with the technology curve.

    Globus XIO provides a single API to any wire protocol. The API has a very common look and feel making it very intuitive to use. As new protocols are developed they can be added to Globus XIO in the form of "drivers". A driver is completely hidden behind Globus XIO so when new ones are used, they are transparent to the application developer. Therefore an application programmer can code to the globus_xio user API once and then focus on the applications needs throughout its life cycle. If in a few years down the line they want the same application to work with the latest and greatest protocol for shipping bytes around the Grid, they do not have to change a line of source code.

  • Minimize the development time for creating/prototyping new protocols.

    In grid computing research is done into how to push bytes faster and faster around the grid. Proof of concept is an important part of this research. A problem that often comes up is the time it takes to both design and implement new protocols.

    Globus XIO addressed these issues. Globus XIO provides a driver development interface that allows a developer to concentrate on writing code to implement the protocol. It takes the headache of error checking, asynchronous message delivery, timeouts and other important issues out of the protocol implementors path.

    Also it allows for a maximum reuse of code with the notion of a driver stack. Each driver should be one atomic unit that can be mixed and matched with other drivers. For example: GSI security can be written once as a driver then stacked on top of TCP, NETBLT UDP blast, or any other transport protocol. This makes it much easier to develop the transport protocols, since the only focus on the developer are the details of the protocol they are creating.

Features

Globus XIO is a feature-rich runtime system. One of its two main goals is to provide the application developer with a simple, easy-to-use API. Part of meeting this goal is providing all the built-in features they need. A library is hardly easy to use if its users have to write most of the needed functionality themselves.

Globus XIO features:

  • Simple API

    Globus XIO provides a simple API for all basic functionality. To find Globus XIO useful, you only need to be familiar with open, close read and write.
  • Extensibility with drivers

    Globus XIO is designed to be extended. The library provides hooks to add future protocols.
  • Efficiency

    Globus XIO is designed efficiency. If you only need a highly optimized, efficient IO library, then Globus XIO is a good choice.
  • Timeouts

    IO timeouts are built into the library so the user does not have to set their own alarms to determine if an IO operation is taking too long. With globus_xio, they simply set a timeout value and they will be notified when/if an operation has not progressed for the specified amount of time.
  • Data Descriptors

    Along with a buffer to be written or read, Globus XIO allows the user to pass metadata describing the buffer. Also, after an IO operation has completed, Globus XIO returns a data descriptor to the user. This allows for some interesting extensions. In the future we hope to make it possible for a user to read from the protocol stack and pass the buffer and data descriptor received to a write on a completely different protocol stack and have things automatically massaged and negotiated for compatibility.