 |
| |
|
The LightPeers Framework, the LightPeers Suite of applications, and the LightPeers Contingency Handling are developed as part of the Nomadic Play in Mixed Environments project funded by by ISIS Katrinebjerg and LEGO Company. The project work is conducted in the Center of Interactive Spaces at the Computer Science Department of Aarhus University. LightPeers is a light-weight peer-to-peer (P2P) framework for mobile computers supporting ad hoc groups for learning, gaming, and playing by allowing peers in the field to produce, share, and present digital material in a session. The LightPeers framework includes protocols for: discovery, session moderation, robust sessioncast transmission, and multihop data dissemination. The LightPeers framework is build directly on top of the UDP layer of the IP stack. Besides the core protocols a suite of LightPeers applications has been made for use in an educational setting or for gaming and playing. Please download and try out LightPeers and feel free to contact Bent G. Christensen (bentor@daimi.au.dk) for further information or comments on the project or the prototypes. LightPeers Core Framework have been developed jointly on top of Mono on Mac (by Mads D. Kristensen) and Mono on Windows XP and uses the console as output for logging. LightPeers application Suite have a Graphical User Interface and is thus more tightly coupled to the platform. The application Suite has been developed and tested on PocketPC 2003 and Windows XP. Downloads: .NET 2.0 CF version: LightPeers Core Framework v1.0 for PocketPC. LightPeers application Suite v1.0 for PocketPC. .NET 2.0 version LightPeers Core Framework v1.0 for Windows XP and Mac/Linux on Mono. LightPeers application Suite v1.0 for Windows XP. Config file for all versions. LP_codebase.zip the entire code base. A slideshow presenting LightPeers can be downloaded here.
|
||
|
|
Scenario: As part of two earlier projects iSchool and ContextIT in the Center of Interactive Spaces we developed a context-aware hypermedia framework called HyCon and a number of applications using the framework. Among those applications was the HyConExplorer intended to support pupils to produce, organize, and present digital material by linking, annotating, and tagging gathered material with context information in the field and at the school. More on the HyCon project can be found here. |
|
|
|
Technical setup: The Hycon Architecture was based on a central server storing all the gathered digital material, links, and structures. In some situations and especially in the field this architecture was a disadvantage, e.g., when two pupils in the field wanted to share a picture it had to be uploaded to the server first and then downloaded by the other pupil and often through cumbersome phone internet connections making the operation to take minutes. |
|
|
The LightPeers Framework and Applications: |
||
|
|
LightPeers Architecture: The LightPeers framework is based on a P2P architecture which compared to the client-server architecture of Hycon allows the pupils (or peers) to share digital material directly without having to store it on a server first. Thus, LightPeers supports pupils in gathering digital material without needing an existing infrastructure such as a central server, and furthermore provides discovery, robust transmission, and multihop routing through devices. |
|
|
|
Sessions: A key concept in LightPeers is the session which is the group of peers with registered applications and the produced and shared material. All communication is performed within sessions. Session can be formed in an ad hoc manner, and session peers do not need to be in direct network range of each other within the life time of a session. Actually, messages are updated when session peers come within range again due to the robust delivery protocol. |
|
|
|
Session Management: Session Management is an important part of every application in LightPeers since it provides means to: create, join, and leave sessions which is depicted in the screenshot. For a peer to join an existing session a request for joining is sent to one of the existing session members which then can approve or dismiss the request. If the new peer is approved the approving peer sessioncasts a session update including information about the newly joined peer. As peers in a session are required to only process packets from approved peers the approval mechanism hinders peers to join at will. Existing session peers can also be expelled from the session if one or more of the other session members decides to do that and sends a session update. Thus, LightPeers provides in infrastructure for ad hoc group forming and self moderation, and does not per se restricts the user to conform with certain social rules, but rather it relies on the users to bring their social understanding and behaviour from their everyday life into their use of LightPeers. |
|
|
|
Chat: A fundamental application of devices in network is sending messages between users, e.g., SMS messages between mobile phone users. The Chat application is an example of this where each member can write messages to the other session members much like the functionality of Internet Relay Chat (IRC) networks. Besides providing direct communication between session peers it can also function as a shared log for session activities or shared memo list for the group. A simple Chat application implemented on LightPeers can be seen in the screenshot. |
|
|
|
Sketchpad: A step further than simple text messaging is to have the equivalent of a sketchpad for freehand drawing to allow sketching out figures or concepts that are not easily described in text. The Sketchpad application as shown in the screenshot supports exactly this situation where a session peer can make a freehand drawing which is then shown and shared among all session peers. In fact all of the peers are allowed to draw on the sketchpad and annotate the figures simutaneously supporting collaborative construction of digital material. After sketching ideas out the content of the sketchpad can be saved for later use before clearing it. |
|
|
|
Sketchpad: The Sketchpad have a series of standard background layouts, e.g., blackboard or whiteboard, but also game boards like Tic Tac Toe is included with the application. The users can also create and apply custom backgrounds, for instance by taking a picture and let it be the new sketchpad background to be collaboratively annotated as seen in the screenshot. The custom background is transferred to the other peers which allow the sketchpad application to be used as a platform for simple multiplayer board games as well. |
|
|
|
Vote: In a group of people working or playing together questions can occur that requires decisions to be made on account of the whole group. This situation could be solved by, e.g., electing one person to be in charge or by taken a vote among the group members. The Vote application as shown with a screenshot gives session peers the opportunity to conduct a simple election among the session members. For instance, the Vote application could be used in the situation of deciding on if a peer should be approved for joining the session or not, or if the shared picture is good enough for the project assignment. |
|
|
|
File Share: Traditional P2P applications are maybe best-known for providing file sharing among peers, for LightPeers file sharing is not the main focus but the functionality is nevertheless useful for the application domain intended for LightPeers, e.g., sharing sound or video recordings of interviews made by pupils on field trips. The FileSharing application provides the core functionality of sharing files between session members. |
|
|
|
Peer Ping: A simple ping utility for testing network latency and throughput is also included in the application suite. It allows the user to select a specific session peer to ping and the payload size of the ping packet. This provides an easy low-level mechanism for testing the connections in the ad hoc network and to discover if a peer is within sessioncast range or not. |
|
|
LightPeers Contingency Handling Architecture: |
||
|
|
Contingency Handling: The LightPeers framework is a P2P architecture for mobile devices and as with any other (distributed) system incidents where the system cannot perform optimally occur, e.g., hardware-level issues such as a device is running out of battery power or using up all its storage capacity to software-level issues such as framework components or applications crashing, and at a session-level with inter-peer interaction where peers are moving out of network range leading to shared resources and services becoming unavailable. Many of these contingencies are not direct faults of the system but inherent properties of its intended use, thus gracefully handling these contingencies would improve the robustness and reliability of using LightPeers. This motivated us to provide a Contingency Handling architecture with LightPeers consisting of: Monitor, Engine, and User Interface (UI) components as depicted in the figure. The Contingency Handling components are running completely separate from the other LightPeers components and communicate asynchronously (through UDP) with the Context Manager to retrieve peer and session information. |
|
|
|
Local Peer Inspection: Basic information about the local peer is continuously retrieved through the Context Manager component by the Monitor component. The local peer information includes: heart beat, incoming, outgoing, and discarded packets from each component, which provides a simple overview of active components and the performance of the framework. |
|
|
|
Session Inspection: Besides local peer information the sessions that the local peer is participating in may also be inspected. This is usually performed to inspect which peers are in sessioncast range and to get an updated view on the roles and capabilities of each session peer. The Session inspection begins by selecting the session to be inspected as shown in the screenshot where Group1 has been selected. Then the session peer IDs (their mac addresses) and the pre-known information are listed. |
|
|
|
Session Lookup: The next step is the actual lookup which is realised through a Lookup Packet that is sessioncasted and replied to with full peer information including: name, roles, and capabilities, and implicitly if they are within sessioncast range or not. Each peer has a number of roles they can act as in the session such as:
For each role a priority of how willing the peer is to act as this role within the session is provided. A list of capabilities that the peer is willing to share with priorities is also provided. |
|
|
|
Normative Sessions: The Session Lookup mechanism can furthermore be used together with Normative Session which is a session configuration listing required roles and capabilities plus desired/optional roles and capabilities that should be present within the session for it to perform optimally. A normative session is usually used for expressing the needs to perform a certain session task optimally, e.g., a Field Trip or a Game Tournament. A normative session for a field trip, e.g., could require the roles: driver, archivist, and presenter and the capabilities: gps, camera, sound recorder. The desired role(s) could be: organizer and the desired capabilities could be: printer and large display. Each role and capability can have multiplicity other than one, e.g., the normative session can require that three archivist peers to be present at the same time. |
|
|
|
Validation with Normative Sessions: The normative session can then be used for validating the current state of a selected session (present peers with their roles and capabilities). This is performed with a session lookup where the replies are matched up to the entries in the normative session. If several peers can act as the same role (or share the same capabilities) their priorities are used to sort them and select the peer(s) that are most willing to take on the role (or share the capability). The status of the validation is divided into:
|
|
|
|
Validation with Normative Sessions: The same session can be validated against different normative sessions, e.g., if the task of the session is changing. When a peer is matched to a particular role or capabilitity a packet is send back to notify the peer of the selection that the particular role or capability is active. In this way only the most appropriate peers are selected in the reconfiguration, e.g., if two peers both share a printer within the session the printer with the highest resolution is chosen (based on capability priority). In this way contingencies that appear due to peers going out of sessioncast range (or change their roles or capabilities) are handled dynamically by reconfigurating the peer responsibilities. |
|
|
|
Editing Peer roles and capabilities: After a session is validated against a selected normative session the status of the chosen peers for roles and capabilities can be inspected. The user can also choose to edit the roles and capabilities the peer provides to the session in order to meet the requirements of the normative session. E.g., take on another role or attach a printer. With the normative sessions and through the validation mechanism an updated view of the validation status is available for the user. This information gives a practical view of how the session can perform a certain task, and what roles and capabilities are possibly missing. The user is put in control of changing the status, e.g., missing roles by having the tools to dynamically edit roles and capabilities. |
|
|
Practical Usage of the LightPeers Contingency Handler: |
||
|
|
Session Showing with the Presenter application: LightPeers Applications can directly access and subscribe to the status of peer roles and capabilities, and can take appropriate actions depending on the current status. As an example of this the Presenter application provides a session show mechanism where the user can select a picture to be shown on the peers acting (or having the role) as active presenters. Several peers in a session may wish to act as presenters, so when the user selects a picture for session showing it also triggers the Contingency Handler to validate the session and thereby select which peers to have the role as presenter. E.g., a laptop peer with a projector attached may have the highest priority as presenter in a session with other PDA peers. |
|
|
|
Session Showing with the Presenter application: When a change in the session context occurs, e.g, a peer is getting out of network range, this also triggers the Contingency Handler to validate the session and possibly appoint new peers for having the roles of presenters. E.g., if the laptop peer with the projector is located in a meeting room and the users having the meeting decide to walk down to the lab to see a demo then as the laptop is not available anymore one or more of the PDAs are selected as presenters dynamically. When they arrive to the lab a Smart Board peer is discovered and has the highest priority which makes it the new selected presenter. The handling of these context shifts (or contingencies) and appointing of roles are being taken care of by the Contingency Handler dynamically. Mechanisms such as: session save (for files), session print, session play (for audio) may behave similarly to session show. |
|
|
|
Session Saving with the Archiver application: When working in a session, peers might want to persistently store shared material on the best suitable of the peer devices and for this the Archiver application can be used as it provides a session save mechanism. When a user session saves a file it is stored on all active archivist peers in the session. An inactive archivist do not store files, but is used as browser for the distributed archive of session saved files and allows the user to manually request a local copy of archived files. The screenshot depicts such an inactive archivist peer browsing the archive after it has requested a local copy of the file IMAGE_00002.jpg. Whether a peer is acting as an active or inactive archivist is decided by the Contingency Handler based on priority and availability. E.g., a group of pupils on a field trip gathering digital material for their project might want to store the gathered material in a shared archive, and if the active archivist peers are not accessible due to being out of network range or running out of storage then other peers are automatically appointed as archivists by the Contingency Handler. |
|
|
|
Session Saving with the Archiver application: The Archiver application places its local archive in a directory on the file system where files also can be copied directly to and from which will then be reflected back in the application. The screenshot depicts the archive directory of the inactive peer from the example above after it has requested a local copy of the file IMAGE_00002.jpg. The default system File Explorer is used for this.
|
|
|
|
