Overview

VLink is a simplified version of the KioskNet system, which is built around the Opportunistic Communication Management Protocol (OCMP). OCMP is an application-layer protocol that supports the abstraction of file transfer between directories (similar to the directory-based FTP protocol in Plan 9). It provides segmentation and reassembly and the scheduling of ‘bundles’ over one more Connection objects (COs), described next.

Similar to an operating system device driver, a CO running on a client system (say a rural school) abstracts reads and writes to a NIC that provides a communication path to a corresponding OCMP instance running at a proxy node on the Internet (say at a nearby town or city). Examples of CO types are a TCP CO (for an always-on link or a dialup link), SMS CO (for communication over SMS on a tethered cell phone), and a USB-key based CO, where the file system on the USB key is used to store packets in transit, and communication is achieved by physically inserting and removing the USB-key from the client and proxy systems.

An example of the use of the system is as follows:

• A file is placed in a special communication directory in a desktop PC at the rural school
• The directory watcher component of OCMP notices this, fragments the file, and stores it in a local database, awaiting a communication opportunity
• If a USB key is plugged in, a USB CO Java object is instantiated and the file fragments are transferred to the USB key. (High priority files can be sent on the SMS CO or, if there is wired connectivity, over the TCP CO wrapping that link)
• When the USB-key is removed and transferred to the proxy desktop in the city, incoming fragments are processed and acknowledgements sent
• When a file is fully received at the proxy, an application-specific handler is invoked to carry out processing. For example, it may call exim or sendmail to send mail to an Internet destination
• A similar process in the reverse direction allows transfer of files from the proxy to the client

In prior work, we implemented a full PKI so that every user in the system can receive encrypted messages, and all data sent ‘on the wire’ by a CO is encrypted. Therefore, if a USB key is lost, data is not compromised. Moreover, the use of acknowledgements, epidemic flooding, and aging-based data discard allows for highly-robust communication despite loss, delay, duplication, and disconnections.

We have already implemented access to Gmail and Hotmail using our system, thus allowing field workers of NGOS to access their email using our system. Moreover, email attachments can include video or voice, so that our system can provide infrastructure for a variety of education, health, and e-governance applications.

Software details

VLink is implemented as a Java application in user space. Each Link is a Java thread that provides the abstraction of a standard device driver. TCPLink uses TCP for end-to-end communication despite disconnections and IP address changes at the client end. SMSLink uses Nokia FBUS commands over a serial line to access a Nokia phone. KeyLink stores packets in the form of files in a USB Key.

The base communication layer is TCP/IP that is present on all desktops. The OCMP layer layered on top of TCP provides disconnection-tolerant end-to-end connectivity. We use flooding-based routing for robustness: every packet is flooded until it is acked or it expires due to a timeout (the default timeout is one day).

OCMP can be viewed as a disconnection-tolerant and policy-driven session layer that runs over both USB and standard links. Each type of available communication path is modeled as a connection object (CO) within OCMP. For instance, the USB mechanical backhaul path is encapsulated as a USB CO. There are similar COs for a TCP connection bound to each type of NIC (GPRS, EDGE, WiMAX, dial-up, etc.).

OCMP allows a policy manager to arbitrarily assign bundles to transmission opportunities on COs. This scheduling problem is complex, because it has to manage many competing interests: reducing end-to-end delay, while not incurring excessive costs, and maximizing transmission reliability. We do not know of an adequate solution to the general problem. Therefore, in the current implementation, we merely send application-specified `urgent' data on an always-on connection (if that is available) and other data on the mechanical backhaul CO. The design of our system, however, allows the use of more sophisticated scheduling policies without changing the rest of the system.