The MindStream Project

Vision Problems Solution overview Details Status Future work

The vision Suppose you wanted to share your thoughts with the world in near-real time. One way to do so would be to record your thoughts (and pictures you take) on a PDA in a ‘weblog’ (or blog) format. But you still have to publish it on your website. Wouldn’t it be nice if, as you walk past an Internet hotspot (or the hotspot drives past you) your PDA could automatically log you in to the network and update your blog. Unfortunately, no system currently allows you to do this. For this vision to become reality, we have to solve some hard problems in connection establishment, identity management, and wireless network flow control. The goal of the MindStream project is to build a prototype that has a first cut solution to these problems. Problems s Here is an overview of the system: The figure shows a PDA that is in Hotspot 1 moving to a ‘dead zone’ then to Hotspot 2. Ideally, the connection from the PDA to the Web server (used to upload the blog) should be automatically established, and unbroken despite movement and despite disconnection from the network when entering the dead zone. A plain vanilla TCP connection won’t do for three reasons: When in a ‘dead zone’ the PDA’s operating system would find no path to the server, and would (eventually) disconnect any open TCP connections, aborting data transfer. If Hotspot 2 assigns a new IP address to the PDA, the web server cannot resume the old TCP connection, since the endpoint identifier (IP address + port number) has changed TCP deals very poorly with packet losses, and can get ‘frozen’ due to very long timeouts, so that when the PDA is a region with marginal wireless connectivity, essentially no data transfer can take place. For these reasons, we need to think of a different way to manage the connection between the PDA and the web server, i.e. do better connection management. A second set of problems has to do with hotspot detection. How should the PDA automatically find a hotspot? And if it finds more than one, which one should it use? What if the hotspot requires a password? Should the user be asked to key in a password every time? Solution overview Our solution is to use a proxy server that is disconnection- aware. Whenever the PDA detects the presence of a hotspot, it establishes a connection with the proxy and sends it bundles of information. The proxy reassembles bundles that come from the same PDA, even if the PDA’s IP address has changed. So, while transferring a long file, for instance, even if the file is partially sent from one hotspot, the PDA can continue transmission of the file from another hotspot. This solves problems 1 and 2 above. Problem 3 remains, and to solve it requires us to re-implement a loss-insensitive transport layer over UDP. We do not tackle this problem in this project. Our initial application tries to transfer a file in a ‘briefcase’ directory on the PDA to a web server using an intermediate proxy server. This application will help us better understand the challenges of uploading from a wireless device where fluctuating connectivity is transparent to the application layer. Details Now to the nuts and bolts! We are working with Linux-based PDAs (from Sharp). For transmitting bundles we are using software from the DTNRG group. Unfortunately, the DTN software does not yet provide segmentation and reassembly, so this is implemented at a file transfer layer above the DTN bundle layer for now. Eventually, we will move this code into the DTN bundle layer. The main issues we deal with are: detecting that a hotspot is present and automated login segmentation and reassembly of a file over the DTN layer the mobile blog application itself, that uses these two components These are described in greater detail below – refer the following figure for the protocol stack we have implemented. Hotspot detection The first link in the chain of events is detecting a wireless network. This involves 'sniffing' for beacon frames that indicate presence of an access point. We have written a small application for this purpose. This application automatically detects hotspots by sniffing for beacon packets automatically logs on the user, or if the user has not used that hotspot before, pops up a window to ask for a login and password, saving this information in a keyring for future use If successful, it then notifies the client-programs that a connection is established. The main challenges are: a. the time-varying nature of the radio signal received by a traveling handheld b. the fuzzy boundaries of a hotspot We are re-using some code from the Kismet project for this. MindStream segmentation and reassembly (SAR) This SAR layer’s functionality is to provide reliable file transmission despite disconnections. This is done by fragmenting files into smaller bundles with enough attached metadata to allow later reassembly. This allows resumption from a partial file transfer. This work involves two halves, a client side that fragments and sends bundles and a proxy server side that receives and reassembles bundles. The client side is built as a library, whereas the server side runs as a server daemon. Applications receiving files from the server side register a callback using a ‘service name’ and a service IP/port by connecting with the proxy server side using a socket on a well-known port. Mindstream application This a client/server application that uses the file transfer layer to send files from a wireless PDA to a particular network host. The client periodically queries a special directory on the PDA – a network briefcase - for files to upload to the host. When a file is available, the client asynchronously sends it to a proxy server using the file transfer layer API, which transparently handles any loss of connectivity and change in network domain that may occur during the lifetime of the file transfer. The file proxy server receives a complete copy of the file from an intermediary bundle forwarder and transfers the file via ftp to its intended host destination. Status The three components of the Mindstream project were implemented during Fall 2003 by Mir Tariq (hotspot detection), Stephen Fung (SAR), and Patrick Darragh (application). You will soon be able to download their code from here. Future work We plan to continue work on the Mindstream project in the coming terms. To begin with, we will clean up the existing implementations to make them robust. We will also merge the SAR layer into the DTN bundle agent layer. At this point, we will start performance measurement and tuning to study the behavior of the application as it enters and leaves hotspots, and the overhead to file transfer added by the DTN layer. In parallel, we will add a major new functionality to our application: the ability for a server to inject a file into the PDA no matter where it may move. For this to work, the PDA must continuously update its location in a global directory. Instead of using DNS, we plan to use the Internet Indirection Infrastructure. In this architecture, a PDA would update a ‘trigger’ in a Distributed Hash Table (maintained by I3) as it moved from hotspot to hotspot. A sender of data would send data to the trigger, transparent to the mobility of the PDA. The resulting architecture and protocol stacks are shown below.