Architecture overview
KiosksEach kiosk has a kiosk controller, which is a server that four or more recycled PCs can boot off of. This server provides network boot, a network file system, and user management. Network connectivity can be available through dial-up, GPRS/SMS (GSM), VSAT, or mechanical backhaul. All kiosk controller come equipped with WiFi NIC, which allows wireless users to connect to them. Our prototype uses headless and keyboard-less low-power single-board computers from Soekris Corp. (http://www.soekris.com) as kiosk controllers, although the controller functionality can be implemented in any commodity PC. The kiosk is expected to be used by two types of users. Most users would use a recycled PC that boots over the network (using RAM disk) from the kiosk controller, and can then access and execute application binaries provided by the kiosk controller over NFS. Recycled PCs cost approximately $100 and spare parts are widely available worldwide. Moreover, as a shared resource, they are an order of magnitude cheaper than any dedicated resource. A second class of users, such as wealthier villagers, government officials, or NGO partners, could access one or more kiosks, or a bus directly, using their own devices, such as smart phones, PDAs, and laptops. Such users would use the kiosk controller or bus essentially as a wireless hotspot that provides store-and-forward access to the Internet. The set of kiosks in the same geographical area, and administered by the same entity, comprises a KioskNet region. Regions not only have administrative significance, in that all entities in a region are certified by the same certificate authority, but also have routing significance, because data bundles are flooded within a region. The figure above shows a system with two regions, which could both be potentially managed by a single administrative entity. FerriesAlthough kiosk controllers can communicate with the Internet using a variety of connectivity options, our focus is on the use of mechanical backhaul. This is provided by cars, buses, motorcycles, or trains, that pass by a kiosk and an Internet gateway. We call such entities ferries. A ferry has a single-board-computer that is powered from the vehicle's own battery. This computer has 20-40GB of storage and a WiFi network interface. It communicates opportunistically with the kiosk controllers and Internet gateways on its path. During an opportunistic communication session, which may last from 20 seconds to 5 minutes, we expect 10-150MB of data to be transferred in each direction. This data is stored and forwarded in the form of self-identifying bundles. Ferries upload and download bundles opportunistically to and from an Internet gateway. GatewaysA gateway is a computer that has a WiFi network interface, storage, and an always-on connection to the Internet. Gateways are likely to be present in cities with DSL or cable broadband Internet access. A gateway collects data opportunistically from a ferry and stages it in local storage before uploading it to the Internet through the proxy. A region may have more than one gateway. ProxyWe expect that most communication between a kiosk user and the Internet would be to use existing services such as e-mail, financial transactions, and access to back-end systems that provide government-to-citizen services. Legacy servers that provide such services typically can neither deal with long delays and disconnections, nor easily modified. Therefore, we need a disconnection-aware proxy that hides end-user disconnection from legacy servers. We currently assume that there is one proxy per region. The proxy is resident in the Internet and has two halves. One half establishes disconnection-tolerant connection sessions with applications running on the kiosk controller or on mobile users' devices. The other half communicates with legacy servers on behalf of disconnected users. To support application-specific protocols with legacy servers, we allow an application to create an application-specific plugin at the proxy. For example, a proxy that handles users' email needs to implement SMTP to communicate with legacy mail servers. Data forwarding between the two halves is therefore highly application dependent. In the case of email, data communication between each half of the proxy must maintain SMTP headers as well as the underlying MIME format of emails. Applications installed at the proxy coordinate with a corresponding application at the kiosk controller or mobile device that reverses any changes made at the proxy.
In the opposite direction, when a kiosk user wants to send data to the Internet, it is carried to a gateway, which transfers it to a proxy. The proxy passes received data to the associated plugin, which interfaces with legacy Internet servers. For instance, in the case of email, the proxy plugin would forward Internet bound emails using SMTP. Besides serving as an application-layer gateway, a proxy provides a central point of management. It runs a DNS-based location register that is used for location management, as described here. It also maintains a Whitepages database that maps from a user's globally unique identifier (GUID) to its X.509 public key. This database, which is replicated at each kiosk, allows secure communication among KioskNet users.
|
 |
