1. The Globus eXtensible Input/Output System (XIO): A protocol independent IO system for the Grid Bill Allcock, John Bresnahan, Raj Kettimuthu and Joe Link Argonne National Laboratory

2. Grid IO l Geographically disperse resources u Supercomputers/clusters u Large data store u Specialized scientific devices l Telescopes, environmental sensors u Collaborative sessions l Access Grid l Varying network and file transfer protocols u TCP, UDP, XCP, GridFTP etc

3. Typical Approach

4. Example Application

5. Problems l Development time u Application must learn to use many different APIs u Each API has its own semantics l Asynchronous/Synchronous l Threaded/non-threaded l Scalability and compatibility u Application must be modified to work with new protocols/devices u Application must keep up with orthogonal research issues

6. Observations l Data stream IO abstraction u Many Grid IO needs can be treated as a stream of bytes u Open/close/read/write functionality satisfies most requirements l Protocol details u Rarely does the application need to deal with protocol details u Most needs can be satisfied at initialization time

7. Solution l Globus XIO user API u Single API/single set of semantics u Simple open/close/read/write API l Driver abstraction u Hides protocol details u Allows for extensibility u Drivers can be selected at runtime

8. Globus XIO Approach

9. Example Application with XIO

10. Drivers l Make single API do many types of IO l Specific drivers for specific protocols/devices l Transport u Moves data out of process space u TCP, UDP, File etc l Transform u Manipulate or examine data u Do not move data outside of process space u Compression, security etc

11. Stack l Transport u Exactly one per stack u Must be on the bottom l Transform u Zero or many per stack l Control flows from user to the top of the stack, to the transport driver

12. Driver development l A set of function signatures u Implemented by the driver u Registered with Globus XIO l Semantics u XIO makes calls to these functions expecting specific behavior u Read() interface function should produce data and write() should consume data

13. Attributes and controls l Way to expose functionalities specific to a protocol l User API to control the attributes and special features of a driver u An opportunity to tweak parameters specific to a driver l Attributes and controls support is optional and a driver may choose not to have it

14. Globus XIO Framework l Moves data from user to driver stack l Manages the interactions between drivers l Assist in the creation of drivers u Asynchronous support u Close and EOF barriers u Error checking u Internal API for passing operations down the stack

15. Existing drivers l Transport u TCP, UDP, File, GridFTP u UDT - UDP based reliable data transport protocol u Multi-stream - uses multiple transport protocol streams for data transfer l Transform u GSI, HTTP, Ordering

16. Performance analysis l Compare with raw sockets and Globus IO l Latency tests u Ping-Pong tests, 1000 times, average of 10 runs u Loopback, LAN and WAN l Bandwidth tests u Send 1000 back-to-back messages and wait for reply, average of 10 runs u LAN and WAN

17. Latency over Loopback Interface

18. Latency comparison on LAN

19. Latency comparison on a WAN

20. Bandwidth on a LAN

21. Bandwidth on a WAN

22. Multiple drivers on a stack

23. Summary l Provides a simple and uniform IO API u Appropriate for most byte stream oriented applications l Ability to quickly adapt to u Different transport protocols u Different data access mechanisms l Provides a convenient framework for research and development