Applications

KioskNet applications communicate with legacy servers on the Internet on behalf of disconnected users. Architecturally, applications run on top of the OCMP layer and have two components. The primary component runs on the proxy and a (typically) small helper application runs on the kiosk controller. Applications may be written in any language, including shell scripts. They pass application data to and from the OCMP layer using a directory based API (described next).

Directory API

The Directory API is a branch of the file system where applications place data for OCMP to process. Each KioskNet user has its own directory within the Directory API, and each application has its own branch within each user directory. Each application directory has an upload and download directory to hold data going to and coming from the proxy respectively. These directories hold configuration files that indicate the processing that needs to be done on the files, and can be viewed essentially as a way to pass application-specific parameters to OCMP.

When data arrives in a kiosk download directory or a proxy upload directory, OCMP invokes an application callback specified in the configuration file to handle the newly received application data. We rely on another application, the directory watcher, to periodically scan the directories under the Directory API to check for newly added files, which are then passed to OCMP over a loop-back socket. Further details of the Directory API and Directory Watcher can be found here. Although the use of a directory based API is slightly less efficient than passing data to OCMP directly, we found that it greatly eased application integration. In any case, the added delay incurred by polling for updates is negligible compared to the time required to transport data over a mechanical backhaul.

Secure Directory API

Building on the Directory API, the Secure Directory API provides a simple interface for end-to-end secure communication. We envision that it can be used for a variety of secure applications, such as bill payment, e-governance, and rural banking.

For every upload and download directory in the Directory API, there is a corresponding ``secure upload and ``secure download directory. A file created in the secure upload directory is encrypted with a nonce, and the nonce is then encrypted with the recipient's public key. A hash of the file is signed and then copied to the upload directory. The sender's certificate is also appended to the data to ensure that only authentic KioskNet users are able to send bundles. The file is then transmitted using the Directory API and appears in the download directory of recipient(s). Any delivered files that are are marked as `secured' are decrypted and copied to a secure download directory in plain-text form. The secure directories are stored within the user's encrypted home directory. The secure data is also authenticated using the sender's certificate chain and the digital signature contained in each secured bundle.

Example applications

We have developed several applications that utilize the secure and non-secure Directory API. We now present three representative applications: email, database synchronization, and an opportunistic Flickr client.

Email

The store-and-forward, delay-tolerant nature of SMTP fits perfectly within the KioskNet architecture. Email service within KioskNet consists of five components:

• Client: The client application can be any standard email client such as Thunderbird or Outlook Express. The client runs on the recycled PC. The email client is configured to fetch a user's email from the kiosk controller using IMAP. Its outbound SMTP server address is also configured to be the kiosk. From the perspective of the email client and its user, emails are sent and received as if the recycled PC was connected to the Internet.

• uw-imap: Any IMAP server can be used to serve emails from the kiosk controller to the email client running on the recycled PC. We chose to use UW-IMAP because it supports the widely-used mbox family of email collection formats, has a small memory footprint, and was simple to deploy compared to other open source IMAP servers.

• sendmail: Sendmail implements the SMTP protocol between the email client and kiosk controller and between the proxy and legacy SMTP servers.

• Kiosk controller component: The kiosk controller component of KioskNet's email service is implemented as a plugin to sendmail (milter). When receiving emails sent from the recycled PC, the plugin is responsible for intercepting SMTP traffic from the email client and compressing it for transport across to the disconnected network. When receiving an email from a ferry through OCMP, this component translates email from SMTP format into mbox format and adds it to the user's inbox.

• Proxy component}: The proxy component is also implemented as a sendmail filter. This component receives emails destined for KioskNet users from SMTP servers on the Internet. Like its kiosk controller counterpart, emails are compressed for transport. When handing emails sent from kiosk users, the proxy component simply decompresses the outbound message and passes it to sendmail for delivery.

Database Synchronization

We anticipate that a major use of KioskNet will be information distribution for data such as agricultural databases and property records. Furthermore, every kiosk must have access to the whitepages directory of public certificates in order to initiate secure communication. To this end we wrote DBSync, a robust database synchronization mechanism. DBSync periodically takes a snapshot of a central Postgres database using the ``pg_dump utility. The snapshot is distributed it to all kiosk controllers using OCMP's directory API. Kiosk controllers have a local database and can use the ``pg\_restore utility in conjunction with the snapshot to synchronize with the master database. Note that a naive dump is not scalable since updates have to be broadcast and a single update will require the transmission of the entire database. Instead, we generate a diff at the central database using the most recent prior snapshot and the current snapshot. The diff is transmitted to kiosk controllers which use the patch utility to combine the current snapshot with updates before restoring database state. This allows us to keep a large database synchronized with minimal overhead.

Flickr upload

This application allows a user at a kiosk to upload pictures to flickr.com. The user takes pictures with his or her WiFi-enabled camera phone. The client-side application on the phone submits the picture files to OCMP using the Directory API. These files are automatically transferred to the kiosk or the ferry, and eventually arrive at the proxy. The proxy-side plug-in for the Flickr application then automatically uploads the pictures to the user's album using the user's credentials through the XML-RPC based API provided by flickr.com. We anticipate that this is useful for NGOs that want to monitor rural infrastructure.