One.box – Universal Inbox System

Albert Wong ()

Boris Startsev ()

Daniel Cheah ()

Ian Shafer ()

Sherif Fanous ()

Abstract

With the rapid development of high-speed networks and the increase in processing power available to common household appliances, it is likely that we will soon see the emergence of home networks that combine various services, thereby increasing their usefulness. Our goal will be to write a service for such a home network that will provide users not only with the ability to use and administer the services on their network, but also give them a reliable and convenient remote access to said services.

1 Introduction

Given the current trend of technology, there are more and more devices that are network enabled. Devices such as laptops, palm pilots, printers, refrigerators, or anything that perhaps may find a use for sending information to other electronic devices are being made network aware. These “endpoints” of a network provide and subscribe to different services allowing a higher order of integration between different electronic components.

Think about a modern household and how many different electronic devices can be found within – televisions, VCRs, alarm clocks, cell phones, sprinkler systems, lights, etc. A productive association of all these devices may be a wonderful vision, but there is still something wrong with this picture: the user’s actions are bound by his physical location.

“So what?” one might ask, “Why would I concern myself with control of the resources in my house if I am currently away from it?”

Though, as with most things, the issue is not life-critical. Remote access to the resources available in one’s house through some commonly available medium could be a matter of great convenience and comfort. For example, while on vacation or a business trip, have you ever wondered if you remembered to turn off the oven? What about the security system – have you armed it? The chances are you forgot to turn down the heat… but the plane is leaving and it’s too late now. Well with one.box installed on your home network, settling your fears or correcting your mistakes would be as simple as sending an email.

2 Requirements Overview

This section provides an overview of the basic functionality of the services of one.box network.

2.1 one.box

One.box will allow users to use email in the normal fashion and control services registered with one.box. In addition, there will be specialized clients that allow full access to the capabilities of the one.box network including the ability to administer devices and set up access control.

2.2 Email Service

A user can set this up to check his various existing email addresses for email. This allows any existing email accounts to be integrated into the one.box network.

2.3 Refrigerator Service

The refrigerator service will simulate a futuristic refrigerator. It’s abilities will include composing a shopping list based on the types of items currently in the fridge versus the types of items the user would like to have available at all times. Also it will keep track of expiration dates of the products within it and notify the user when the product should be considered expired.

3 Requirements Details

This section describes in greater detail the goals we have set and touches briefly on the reasons behind these goals.

3.1 one.box

The following three subsections cover storage, messaging, and one.box service compatibility guidelines. We have identified these as the core features required.

3.1.1 Storage

One.box services may need storage. Since this will be a fairly common requirement (services needing storage) and it is a fairly complicated resource to manage. One.box will provide a core storage service.

We will require that physical storage space be explicitly setup by the “administrator” of the one.box network. This is necessary because claiming some storage device of unknown characteristics simply because it was found on the network (assuming it could even be found) would be irresponsible. Hopefully, the storage service configuration will be a one-time setup task.

The storage service will allocate storage to any service that makes a request for it. After the storage space is allocated, its use should be transparent to the registered service. This will simplify the creation and implementation of services capable of taking advantage of one.box storage.

If the user has more than one physical storage device available on the network, it presents an opportunity to improve the reliability of our system. To take advantage of this, our storage service will support replication of data. Also, in order to allow client access to data while offline (when using our specialized client software), the user will be able replicate some or all of his data locally.

With replication comes the problem of synchronization. To deal with this problem, one.box will assume eventual consistency. This will be tolerable on a one.box network because if one’s data (e.g. email) is not always completely synchronized, it is acceptable. This is based on our assumption of not having critical tasks and that data is read-only.

The storage service will be required to store data for services. It is not responsible for defining the internal structure of the stored data.

3.1.2 Messaging

Within the one.box system, there are two general types of messages that will be used to communicate with the system. The first are human readable messages, whose intended recipients are people. The second are control messages, which will be received by services that will in turn interpret and perform an action based on the message.

There are two possible kinds of clients that will be communicating to the one.box system.

The first variety of client is the standard email client available today (e.g. pine, outlook, emacs). These clients communicate to the various mail servers around the Internet via the SMTP and POP3 protocols. For these clients to communicate with one.box, they will send email to various email addresses that have been registered with the one.box email service or directly to the personalized one.box email address. In addition, using XML, a sufficiently skilled user will be able to send control messages to the one.box system. In order to ensure that one.box is secure from the dangers of the outside world, it will authenticate the control messages that it receives from clients. In addition, one.box will be using access control lists that can restrict what a control message can do based on its source. This provides ubiquitous access to all the email and all applicable services a user has.

We will also have more specialized clients that have tighter integration with the one.box system. These clients will better support the notion of logging into the one.box network and communicate with one.box using remote procedure calls (RPC). As these clients are more specialized their user interfaces and functionality will leverage the capabilities of the one.box network better. In addition, they will also utilize the same security features that the standard email clients do. By providing better integration with one.box, specialized clients can have more transparent access to the one.box network.

To handle service outages within the one.box network, if the recipient of the message is unavailable when the message arrives, something should be done to ensure that the recipient receives the message when it rejoins the one.box network (e.g. put the message into some well known space that a service looks at when it becomes available again).

For the purposes of this project, we have focused on using email as the primary messaging transport. If time permits and it is feasible, it may be interesting to integrate various instant messaging protocols into the one.box system.

3.1.3 one.box Service Compatibility

In order to be compatible with one.box, all services will be required to implement a core set of one.box interfaces. These various interfaces permit services to utilize the different core features. Also, services will be expected to publish their interfaces so that other services can use them. These interfaces will need to be extensible to allow a fair range of services to be added onto the network.

Additional guidelines may be added, not as absolute requirements, but rather as one.box conventions that will allow services to be better integrated with one.box.

3.2 Email Service

Users will register the email accounts that they wish to have monitored with the email service. Collecting messages involves polling the registered email accounts for new email messages and putting them into storage provided by one.box. The email service will also need to handle the email accounts of multiple users and ensure that email remains private to the user.

3.3 Refrigerator Service

The fridge will be expected to process incoming control messages, and if necessary reply to the specified users. The primary request for the refrigerator is the grocery list request.

The fridge will then check its state, compose a list accordingly and finally send the list to the specified user. It may also send email to a specified user when various food items in the fridge have expired.

4 Assumptions

·  Storage space will not be restrictive (there’s a lot of cheap storage).

·  Memory and processing power are sufficient for our services.

·  There are two kinds of networks – private networks i.e. your own trusted network (in your home, at work etc.) and public networks (the Internet). The infrastructure (the core components) for one.box will run from private networks and be accessible from public networks.

·  Public networks are not reliable nor are they secure, but connectivity is fairly abundant.

·  Data and services used in one.box are not mission-critical. The one.box network makes no assumptions about synchronous behavior of its nodes, thus there can be no guarantee in regards to timely execution of services making it unsuitable for things that require assured execution in a bounded time.

·  Data will be read only.

5 Components

This section lists the main components of one.box and email services and discusses some in detail. Though we have decided that email would be a core service of one.box and, in that sense its component, logically email is a separate entity and is presented here as an independent service.

5.1 One.box

The following are one.box components:

-Lookup

-Storage

-Filter

-Router

-User authentication

-Administration

5.1.1 Lookup

The lookup component allows any service entity joining the network to identify and locate published services on the network. When an entity joins the network, the lookup component will check to see if the entity is currently registered with the network. If not, the lookup component will determine a Globally Unique Identifier (GUID) and assign it to the entity. Having an assigned GUID, the entity can now be uniquely identified by other entities on the one.box network.

5.1.2 Storage

Since most entities will require some amount of reliable storage for data, environment, state or whatever else. The one.box network aims to provide a transparent storage service for all entities

Currently, storage is to be implemented as a single filesystem with a directory entry for each registered service. Following conventional Unix-style directory notation, the organization can be thought of as: “/GUID/” where “/” is the root of the filesystem and GUID is the specific entry in the filesystem for an entity. In addition, the users will be allocated space structured as “/UID/” in order to provide storage for personal services while simplifying the task of management of ACLs.

The interface to the storage system will consist of the following methods: put, get, find, delete. Find will search using a description based on the type of data searched for.

To provide some security, these availability of these methods will be limited by Access Control Lists (ACLs) which will ensure that only authorized entities will be able to read or modify resources.

As for reliability, since this is a transparent interface, it is possible to implement replication, or other forms of backup without affecting interaction with other components.

Also there is a problem of wasted storage space. For example, the user buys a toaster, but returns it to the store the next day (after adding it once to the network), the storage space allocated to the service will remain indefinitely – a rather unfortunate side effect of storage transparency. We could, of course consider reclaiming allocated storage space when the service goes off the network. However, in a dynamic environment, such storage would be useless: the information would be lost every time a connection breaks down or is temporarily disconnected. Our solution to this is long-term leases. A service would lease storage for a certain number of days (let’s say a month) and renew that lease each 24 hours. If the lease is expires, the space will be reclaimed.

5.1.3 Filter

Since one of the main transport methods for one.box is e-mail, a filter component is required to process incoming e-mails and determine whether or not they are regular messages or one.box control messages and storing in the proper storage location for e-mail and sending them to the router if they are control messages.

If security is implemented, the filter is also where authentication and decryption, if needed, will take place. Also, it will double as a verifier and ensure that messages – in particular, control messages – getting into the one.box network are well formatted.