The networked device driver architecture : a solution for remote I/O

With rise of both mobile devices and the cloud, we see users frequently turning to remote servers for both data storage and software services, including running applications. However, once applications are no longer co- located with devices, the traditional device driver architecture no longer facilitates communication between them. Frequently, applications must be rewritten in order to receive data from a remote, rather than local, device. The networked device driver architecture is designed to support input/output devices that are separated by the network from the application(s) to which they are supplying data. The introduction of the network between the device and application also introduces issues such as high latency, low bandwidth, and jitter. We wish to compensate for these problems by alling for the processing of the data sent between the device and application. We also want to maintain network transparency, so that applications do not need to be modified in order to use remote devices. The networked device driver is split into two parts, one on each side of the network. At one end is the device and its unmodified device driver, and on the other end is the unmodified application. An I/O stream that is sourced at one end and sinked at the other may be modified by a set of pipelined transformation modules. Each module comes in a pair, one on each side of the network, with one side typically applying some operation and the other side applying a corresponding one, such as encoding and decoding the format of the data or pausing and resuming the sending of messages. We support network transparency with the pairing of modules, guaranteeing that any modification performed on the data stream will be undone before the message reaches the application. We additionally design our system with the goal of supporting ease of customization/extensibility in support of the vastly different needs of various applications and devices that can benefit from remote I/O. In this work, we explore the necessary trade-offs between ease of development and performance, demonstrating that we can leverage many existing mechanisms without creating a limiting amount of overhea