one.box Distributed home service interface

Core Components Pop3 client Router Storage Pop3 Server

Pop3 Client and Server Client pulls off Pop3 servers (yahoo.com, sumatra, etc) Server allows outside (of one.box network) access to

Router Directs from the Pop3 client or any other internal client. Human readable message is stored in user’s inbox. Control message is sent to the recipient service or is left in the service’s undelivered tuple.

Storage Configuration State

Jini Java framework for distributed applications rmi (synchronous) Provides lookup, discovery, join, activation, lease management, remote events, javaspaces, etc

Services (Fridge) Fridge is the only service Keeps track of contents Calculates grocery list Sends and receives

Setup Register new users Allow users to add, delete, or update accounts Setup once

Setup Features Remote events. Simple GUI, allows for easy account management.

Pop3 Client Features Separate thread for each account. Reconnects to server whenever time interval has elapsed. notifications in case of error.

Storage Features Tuples (TSpaces by IBM) Hierarchal naming structure Leasing Locks Automatic lease management

Normal Operation Pop3 client polls Pop3 server for new Sends to Router Router directs accordingly

Router Down Pop3 client will store undelivered in storage

Router Back Up Router looks in storage for undelivered messages Delivers accordingly

Activation Activation makes things more resilient. Makes restarts simpler. …in theory…

Bad Things Activation (rmid) Why’s that service still up (lease, log) Tough to debug and test (inherent with distributed application paradigm?) Synchronous

Good Things Develop components normally, then jinify A lot of services already provided (lookup, discovery, etc.) Once a jini service is working, it’s very easy to use

One.world More distributed components Printer service Scheme configurable service components We have cooler stuff –But Jini team stuff works better (for now)

Auth Keeps track of users in the system Keeps track of the various authentication information –Data for contacting external pop3 servers Centralized place to store this data –Not a secure solution

Monitor(Pop3 Client) Collects from external Pop3 servers Each monitor serves a different user in the system

Filter Directs from the Monitor Human readable or control message?

Router Gets control message from filter Finds the service control message is intended for

Inbox Holds all the users data Uses checkpoint –Movable too (but not implemented) Data is never deleted

Pop3Server Used to communicate with clients Hardest component to implement –Delete messages here –Distributed state –Mixture of messaging style Asynchronous with rest of one.box Synchronous with clients

ServiceComponent External services implement this interface Scheme configurable Printer is a ServiceComponent

Normal Operation Monitor To Filter Filter Checks Message –If Control Message Send to Router Router sends To Appropriate Service –If Send to Inbox Inbox Stores the

Normal Operation (2) Service Processes Control Message –Printer Pop3Server polls the Inboxes –Downloaded to itself –Serves it to connecting clients

Good & Bad Things Asynchronous events –Pop3Server –Everything else Discovery Transparency

Bad Things Synchronization/Threading complexities Interaction with Swing Harder to one.worldize –ServiceComponent is our solution for one.box

Good Things Integrated System Structured IO Code and Data is shared

Future Work Stability OneBox/Mover/WatchDog New Patterns/Refactoring Better Setup Tools Integration with Other Systems