|
Architecture
|
| Introduction | Remote intenting | Group communication | Device connection | Java API | Tutorials | Architecture | Contact |
Yigong Liu
PeerDeviceNet helps setting up secure ad-hoc peer-peer connections among a group of peer devices and enabling communication among them. Not only the system enables device users to share information (such as photos, videos) with each other, also it is a platform for mobile developers to develop connected mobile applications. It provides APIs to allow applications set up connections among peer devices, join or leave communication groups. It also provides reusable components (connection manager, remote intent services, etc.) which applications can reuse for connection setup and data sharing.
In recent years, mobile computing has entered the mainstream with the advent of powerful mobile devices (smart phones, tablets, and laptops) and modern mobile OSes (Android, iOS, Windows8). Mobile devices are taking central stages in people's daily life, for both content creation (such as taking pictures or videos with phones) and content consumption (such as browsing web, watching video and playing games with tablets).
As the primary computing devices of many, mobile devices need to be able to connect and share easily with each other, such as sharing photos and videos with friends, playing multi-player games with people met in coffee shop, or sending confidential documents to teammate.
Currently web is the central of sharing. People will upload photos to web services such as Facebook or Dropbox and send URIs to friends for sharing. There are many concerns with such sharing, mostly concerns with security. If the web services are hacked, your password and private information (such as photos and videos) will be exposed. More importantly many web services will keep a copy of the information you upload. If you want to share design documents with teammates, your employers may have security policy against using public social sharing sites.
PeerDeviceNet will help solving the above issues. It helps creating secure, impromptu direct peer-to-peer connections among a group of devices. There is no server in the middle of connections between devices and no need to set up any accounts or passwords. It helps creating ad hoc, temporary communication sessions among applications on peer devices with simple APIs for connections and message passing. On top of these facilities, it is easy to build various connected mobile applications such as sharing pictures and videos among devices, and multi-player games.
In a typical situation where PeerDeviceNet is applied, several devices are connected through some kind of network. The devices can be smart phones , tablets, laptop computers or other computing devices. The network connections can be Wi-Fi networks, Wi-Fi direct, mobile hot-spot, blue-tooth or other 3G/4G connections.
PeerDeviceNet will run on each device to help set up direct device to device (or peer to peer) connections. The connections will not go through any servers logically. The connections are not authenticated by some central account servers; but secured through TLS/SSL.
The connections are ad-hoc, temporary and ephemeral in both meanings that the need to setup connection and communication groups are ad-hoc and relative short duration; and the networks and identity (address and ports) of devices participating in connection and communication are dynamic and could change from session to session.
There are different approaches for connecting peer devices depending on networking resources available at the spot. In one instance, such as at home, all peer devices can connect to the same Wi-Fi router, set up communication groups and share photos and videos with each other. Furthermore if this router supports multicast (as most home Wi-Fi routers do), peer devices can find each other with one simple click. In another instance, eg. in national parks, there is no external networking routers available, one smartphone can act as a temporary router by turning on Wi-Fi Direct or mobile hot-spot, and allow other devices connect and share in peer-to-peer fashion.
FIG.2 depicts the architecture of PeerDeviceNet. On each peer device, PeerDeviceNet will be running. As discussed in details below, PeerDeviceNet can have the following 5 modules.
At the bottom of system is a service component for managing peer device connections and discovery (210).
This device connection service (210) contains network monitoring components for detecting network attachment and detachment (211). In one instance, when device is connected to a Wi-Fi router, this component will be notified and it will further forward this event to other components in the system so that they can act accordingly. When device is disconnected from the Wi-Fi router, a similar event will be propagated by this component. Standard interfaces are defined between system and network monitoring components so we can add different monitoring components to support different network types (WiFi, WiFi-Direct, blue-tooth, 3G etc.) in the plug and play style.
The next component of device connection service (210) is peer device discovery (212). Mobile device based communication sessions are ad-hoc and short-lived. There is no one acting as the special role of server (as in Client/Server model) which is always there waiting for others to connect. Devices participating in connection can be different from session to session and they act as peers with similar capacity. The network and identity (addresses, ports) of same device can be different from session to session. So peer device discovery is the necessary first step for connection setup.
The general rule for discovery and connection is that peer devices express their intention for connection or association at the "same spot" in space and time. This is called Peer-Join protocol. It has the following characteristics:
Devices meet at some communication rendezvous point.
Devices publish its connection info (such as address, port) for a limited duration at rendezvous to express its intention to connect. When time is out, device removes its connection info so devices joining rendezvous later will not see its connection info.
Devices receive and record the connection info published by other devices and later use it for verifying connection requests from peers. In one instance this reception process could happen during the same duration when it publish its connection info. In another instance it could happen in other time spans such as active till the rendezvous point closes.
The rendezvous will broadcast the connection info published by one device to all other devices which join the same rendezvous. The rendezvous point could have limited lifetime. When it is closed, no new devices can join the session.
For two devices to discover each other, they must be publishing their connection info at the same rendezvous in the same or overlapping time durations.
In one instance, in a Wi-Fi network with multicast enabled, a multicast group could be used as the rendezvous point. Devices can send its connection info to same multicast group identified by a class D address and UDP port. Devices will discover peers by receiving connection info sent by peer devices from the same multicast group. In another instance, a software service could provide this rendezvous point and it could run on one of peer devices, which will be connected to by other peer devices, receive peers' published connection info and broadcast it to all connected devices.
The means to bootstrap device discovery include multicast, NFC, rendezvous service and more. Standard interfaces are defined between system and peer discovery components so that different discovery methods can be plugged into system in plug and play style.
The 3rd component of device connection service (210) is connection management (213). It includes proper data structures to maintain data about connections with peer devices, both outgoing connections and incoming connections. It also validates the connection parameters and carries out connection operations over various transports such as TCP, UDP or HTTP.
The 4th component is connection manager/verification (214) which includes GUI, work flow and underlying protocol. A connection manager implements a specific connection strategy. In the instance of implementing the above mentioned Peer-Join protocol, a secure connection strategy could be implemented as following. When a device receives a connection request from peer device, the receiver itself must be in connection mode, otherwise the connection will be rejected. In one aspect, the connection request will be accepted only when the connecting device has been discovered by receiver device. We can always bring up a GUI view showing data about connecting devices and ask for user's decision. Further security can be provided via a PIN setting so that devices can be connected only if they have matching PIN strings.
As described in FIG.2, on top of device connection service is the service for managing communication groups (220), which provides group based communications among applications running on connected peer devices.
This communication group service (220) will contain a component for managing group information (221). It includes proper data structures to maintain data about communication groups, identified by some kind of identifiers such as string group names. The group data structures will remember which peer devices are in which groups. A group can contain multiple peer devices and a device can be in multiple groups.
When a application joins a group at a device the first time, the group information is created and automatically propagated (222) to connected devices, so that other applications on connected devices can join if they are in the same group. When a application leaves a group and the group is destroyed, the event will also propagated to connected devices.
When two devices are connected, their groups information will be properly exchanged (223) so that peer devices which are in the same groups are connected automatically and their group information data structures are updated.
Whenever a new peer joins the group or an existing peer leaves a group, the group data structures will be updated and an event is created and propagated to other components in the system so that they can behave accordingly (224).
Another major component of this communication group service (220) is message routing (225). Two kinds of message routing are supported: broadcast based on group identifier and point-point message routing based on device identifier. If a message is sent out using only group id, all peer devices (and their applications) in this group will receive this message. If a message is sent using device id, only that specific device (and its application) will receive it.
In the illustrative architecture, on top of device connection and group communication service is the service for remote startup/activation and data streaming.
Modern mobile OSes (Android, iOS, Windows 8) provide high level mechanism for starting up system and application components and pass data messages between them. In Android, this mechanism is called “Intent”, in Windows 8, it is called “Contract” and in iOS it is achieved through “custom URLs”. In the following, we'll collectively call this mechanism “intenting”.
The OS native “intenting” mechanism is limited to one device, ie, it can only start software components within the same device and pass data between components within the same device. The presented system extends this mechanism remotely to connected devices, allowing activating components at remote devices or send data to remote components. One direct result is that applications which support “intenting” mechanism will be automatically enabled to share data across devices, such that gallery app share its photos across devices. The action to start a software component (activity, service or application) at remote device and pass it required data is called “remote intenting”, and the messages exchanged for this action is called remote intents.
The first component is remote startup and activation service (232). It will intercept applications' request s for remote “intenting”; collect the “meta” data for remote activation, including but not limiting to type of action to be performed, the target data URI, destination device information (address, port), or destination application package name, etc.. It will pack all these data as some kind of data set (bundles or property sets) and send it to destination device through the group communication service discussed above. At destination device, the message will be unpacked and the data structure for OS native “intenting” mechanism will be restored. If the destination device has applications installed to handle this intent, the intent will be fired using native OS mechanism. If not, the system will prompt user to install proper application package whose name could be provided by sender.
The second component is streaming manager (231), on top of which remote activation service (232) is built. Many data exchange between applications involve sending binary data, such as transferring video files or picture files, which is best handled by a separate bi-directional byte streaming channel. If the remote intent requires streaming, remote activation service will invoke streaming manager to set up a raw byte stream bi-direction channel with remote device and return input and output stream interfaces to initiating application which could use the output stream interface to send binary data to remote device and receive binary data from remote device through input stream interface.
In the illustrative architecture, parallel to the above mentioned services for device connection, group communication, streaming and remote intenting, there is a module (240) responsible for exposing programing interfaces (APIs) to developers. By using these programming interfaces, 3rd party developers can access the functionalities of the above mentioned services and develop connected mobile applications.
Because mobile applications and devices are always interacting with users, various sensors (GPS, gyroscope, etc..) and networks in real time, these APIs will expose mostly asynchronous method calls or provide asynchronous message types for implementing responsive applications.
This API module (240) can be composed of multiple levels. In one instance, it can expose a low level interface in the IDL/RPC style for applications with architectures suited for this style. In another instance, applications can use a higher level programming interface in "messaging" style such as “Intent” mechanism in Android and “Contract” mechanism in Windows 8, which are central to components communication and integration in modern mobile OSes (Android, iOS, Win8).
When applications send messages through these APIs, the application data will be serialized and deserialized in a common format and mechanism such as JSON which are understood by all peer systems in the group.