Profile Server Description

Terminology in this Section

server: system responsible for storing and managing user data
scrap device: a borrowable device that is not associated to any user
active device: a borrowable device that has been associated to a user
background app: a background running thread on devices that coordinates with SpotON to notify applications of user proximity

Purpose and Components

The server serves the following purposes:

data storage space for user data.
framework for third party modules to handle application data.
coordinator for data propigation to active devices.

The server is composed of a database storage substrate, along with a Java application framework.

Communication Paradigm

All communication is built over TCP/IP to guarantee service.
Applications on devices initiate connection to the server. The server does not open connections to devices.
Connections remain open to allow two-way communication to and from the server.
Each application opens its own connection to the server. Thus, a single device may have multiple connections open to the server, one for each running application.
Connection termination is initiated by devices.

Originally, we wanted all connections between the server and devices to be built and torn down as necessary. Thus, if a device had something to send to the server, it would open a connection, squirt the data, and close the connection. Similarly, if the server wanted to send something to a device, it would open a connection, squirt the data, and close the connection.

Unfortunately, we found this to be rather difficult to set up. The reason is that in order for the server to open connections to devices, it would have to know the address of each individual device it could possibly want to talk to. This is not a large problem if the devices were fixed to a LAN line, but that's not the case. Because the scrap devices are on wireless ethernet, it is possible that intermittent signals can cause the device to shift address location.

Thus, to alleviate this problem, the device application initiates the connection first, and keeps the connection open to allow the server to send back data.

The reason that each application on a device opens its own socket to the server is a result of how the device applications got developed. Because the applications were written before the background app, they originally had their own networking code in order to test functionality. As development continued, we decided it was too risky to re-code existing applications to funnel all of their messages to and from the background app. Thus, the result is that all applications open their own networking sockets to the server.

These compromises lead to the following problems:

duplicated network code on all applications.
a single device will get multiple broadcast messages if it has multiple applications open.

While these problems are not a big obstacle for our small scale "proof-of-concept" demo, they should be addressed if this project were to be scaled up to full production quality.

Summary of Server Interactions

Required bootstrapping communication:

User opens an application on an active device.
The application sends a logon request message.
The server responds with a logon acknowledge.

Remember that each application must perform this network handshaking, and that the connection created by steps #2 and #3 stay open for the lifetime of the application.

Optional Snapshot Request:

The snapshot request is used by an application to retrieve saved data on the server. Note that the snapshot reply back from the server only goes to the application that requested it. This also assumes that the communication channel between the application and the server has been established.

Application sends a snapshot request to the server. Note that the application sends directly to the server, using its own socket.
Server passes the snapshot to the 3rd party module that handles that application.
3rd party module hands back the return values.
Server packs up the results and sends it to the requesting application.

Optional Update and Synchronization Broadcast

Once the user makes a modification, that modification is sent, via the applications open socket, up to the server. Once the serer has handled the request, it is broadcasted to all applications on all active devices owned by the user. The broadcast includes the originator of the update.

User makes some form of update.
Application sends update message to the server.
Server passes it to the proper 3rd party module.
3rd party module passes return values back to the server.
Server broadcasts synchronization message to all applications on all devices owned by the user.

Summary of Server Implementation

The server is a multi-threaded host. The primary thread listens on the TCP socket 4040. When an incoming connection is detected, the host spawns a worker thread to handle the incoming data package. The worker thread is responsible for determining the packet type, and spawning the necessary 3rd party modules for processing any application specific data.

3rd party modules are required to implement certain interfaces. These interfaces define a return value, which is what the server uses to send/broadcast back to the applications.

Summary of 3rd Party Module Interface

3rd party modules are requred to implement the interface Module.java.

IMPORTANT NOTE:
As a hack, in order to accomodate the instant messanger, the return format for the acceptUpdate method in Module.java is irregular. See the javadoc for more details.