File Sharing App

The app oriented architecture of Fog Computing enables third parties to add piecewise functionality without worrying about lower layer functions like routing or storage. As an example, a file storage and social networking service for first responders can be very useful and improve situational awareness. A traditional file storage service in the cloud has the following functionality and properties: i) The

Parts of this section reprinted with permission from “Distressnet: A disaster response system providing constant availability cloud-like services” by H. Chenji, W. Zhang, R. Stoleru, and C. Arnett. Ad Hoc Networks, vol. 11, no. 8, pp. 2440-2460, 2013. Copyright 2013 by Elsevier.

ability for a client to upload a file to the cloud, without specifying a destination node; ii) The ability for a client to retrieve a file, without specifying the location of the file; and iii) Data robustness due to intelligent replication performed by the cloud service back end. The file sharing application allows authenticated users to share data with other users, or groups of users. As an example, one can imagine a team of responders sharing the layout of an explored building along with current hazards, with other nearby teams. An important feature that emphasizes the need for such a service is that the destination for data sent is unknown - it is simply stored in the Fog and accessed by anyone who connects to the Fog Computing infrastructure.

The File Sharing App can be seen as a client/front end, designed to be used by a first responder, that connects to a File Sharing Service server/backend and authenti- cates itself. The clients can then use the Fog API to ADD/DELETE/MODIFY files which they own (as determined after authentication), as well as specify availability metrics depending on the importance and criticality of the data file. They can also share selected files with other clients or users. Examples of files that users can upload include video taken using a smartphone’s camera. Users can also specify whether they want to backup these files to an external storage provider like Amazon S3 or Flickr. If a client wishes to use their own external account, an encrypted query, using the provider’s API (S3’s API or Flickr’s API), is sent to a special device that has both the File Sharing Service as well as internet access. The HTTP header and body is intercepted by the File Sharing Service and sent to the internet Gateway using the Fog’s underlying network.

5.1.1.1 Fog API

The Fog API insulates the user, first responders in this case, from the inner workings of the underlying network. It aims to provide a service similar to those

offered by cloud storage services like Dropbox and Amazon S3. Three primitives called ADD, DELETE and MODIFY provide an interface into the Fog. The ADD primitive uploads a file into the Fog. This file could consist of a tweet as produced by the Social Networking App (to be presented next), or a photo from the user’s phone as produced by the File Sharing App. The MODIFY/DELETE primitives allow users to modify or delete files that they own.

When an ADD request is sent from the File Sharing App to a nearby device running the File Sharing Service, the file is first transferred locally to the device. Then, the file is replicated on multiple Fog devices according to the criticality of the data. The actual Fog devices that are chosen as endpoints depend on the output of several algorithms to be presented later in this dissertation. A MODIFY operation causes the File Sharing Service to send the difference between the current version of the stored file and the new incoming file to the Fog devices which contain the original. These devices will locally modify their copy of the file and push it to another user’s File Sharing App upon connection. The DELETE operation simply sends a low overhead message to the Fog device which says that the local copy of the file on the device should be deleted. The synchronization between the devices running the File Sharing App and File Sharing Service occurs as follows: when an App discovers a Service nearby, it can supply a list of files stored locally and ask for changes to those files. The Service then replies with a list of changes, which the App can apply to its local copy.

5.1.1.2 Security

API level security is available if the user chooses external service providers - thus providing encryption on an end to end basis for the user. Users need not disclose their existing external credentials in order to use the Fog. We consider Amazon

S3 as an example of an external RESTful cloud storage service provider. Files are uploaded to S3’s servers using a published API which offers both a REST and a SOAP interface using XML. When a user signs up, a secret key is assigned. This secret key is then used alongside HMAC-SHA1 in order to authenticate all HTTP (optionally, HTTPS) requests. Whenever a user wishes to place a file in S3, a challenge string is first constructed based on a predefined ruleset, which then serves as the “message” in HMAC-SHA1. The output, which is a base64 encoded string, forms part of the HTTP request header. The entire HTTP header and body (if applicable) is then sent to Amazon by the client.