PECOLE: P2P multimedia collaborative environment

PECOLE: P2P multimedia collaborative environment

Abdulmotaleb El Saddik & Abdur Rahman &

Souhail Abdala & Bogdan Solomon

Published online: 8 August 2007# Springer Science + Business Media, LLC 2007

Abstract PECOLE (Peer-to-pEer COLlaborative Environment) is a fully decentralizedmultimedia collaborative environment that supports a wide range of collaborativemultimedia applications, including chat, shared browsing, shared telepointer, multipoint-to-multipoint audio/video conferencing and multilingual collaboration. PECOLE canintelligently run on very constrained resources, is highly resilient, scalable and does notrely on dedicated servers. Instead, PECOLE is built upon a Peer-to-Peer (P2P) overlaynetwork, using SUN’s JXTA framework and SWT technology. In this paper, we present thearchitecture and implementation of PECOLE with the performance results of the tests weconducted.

Keywords Collaborative multimedia . JavaMedia Framework . JXTA socket .

Peer-to-peer . SWT

1 Introduction

Multimedia communication is the field that is concerned with the representation, storage,retrieval, and dissemination of machine-processable information that is expressed in multiplemedia, such as text, voice, graphics, audio, video, haptic, and 3D scenery. Multi-participant/collaborative multimedia communication refers to an area in multimedia communication whereseveral participants are engaged in real-time in a multimedia session. In that session, users can

Multimed Tools Appl (2008) 39:353–377DOI 10.1007/s11042-007-0165-0

A. El Saddik (*) :A. Rahman : S. Abdala : B. SolomonMultimedia Communications Research Laboratory, University of Ottawa, Ottawa, Ontario, Canadae-mail: [email protected]

A. Rahmane-mail: [email protected]

S. Abdalae-mail: [email protected]

B. Solomone-mail: [email protected]

either interact with each other, collaboratively manipulating the media in the session(conversational session), or they can simply receive the information that is broadcasted(playback) to all participants, without any interaction capabilities (presentational session).

Multimedia collaboration in real-time can be challenging when all the participants aregeographically distributed. Collaborative systems such as instant messaging, shared browsing,video conferencing are among the most successful and widely used distributed applications.Nowadays, the vast majority of these services are widely implemented based on the popularclient–server architecture. Few researches have been done to implement these services in a fullydecentralized environment [20]. Data and/or events and messages are stored on and routedthrough dedicated servers, each hosting a set of user accounts/profiles. This partial centralizationlimits availability, because a failure or attack on the central unit (server) denies service to theusers it supports. Also, substantial infrastructure, maintenance and administration costs arerequired to scale to large numbers of users. P2P networking is the next generation in distributedcomputing. Instead of clients and servers, each entity participating in the system acts as both aclient and a server. Sun Microsystems’ project JXTA [18, 19], an open source effort, uses XMLtechnology as its file format, to make P2P network inter-operable. JXTA aims at making thecommunication ubiquitous thereby crossing the communication boundary. It is networkindependent, and can operate over TCP/IP, UDP/IP, Bluetooth, and other wireless technologies.JXTA can also route packets across Network Address Translation (NAT) protocol, DHCP, andfirewall boundaries. Figure 1 shows a JXTA-based P2P virtual network in which an overlaynetwork is formed on top of the physical network.

While some of today’s available technologies, such as JXTA, provide us with basicmodules to be used in the design and development of distributed multimedia collaboration,

Fig. 1 P2P virtual network showing the overlay network

354 Multimed Tools Appl (2008) 39:353–377

[5] there is still a long way to go before providing complete ubiquitous collaborationsystems to users, requiring advancements in most areas of multimedia communication, e.g.hardware supporting low-power high-performance wireless devices, network ensuringconnectivity everywhere, and development support for deploying ubiquitous applications.[8] concluded that for a collaborative system to be deployed in multiple domains, some ofthe following features need to be addressed and implemented. Among these features aremultipoint-to-multipoint audio/video conferencing, shared browsing, moderation capabilityfor floor control and multilingual collaboration with telepointer.

This paper describes a new P2P system called PECOLE that is able to support not onlysharing a web document in a peer group but also synchronously viewing the document andmanipulating the browser content with further support of some group users’ awarenessinformation such as a moderator-peer moving a cursor, entering a new URL and clicking ahyperlink. PECOLE is implemented using JXTA [18, 19] protocol and Eclipse’s StandardWidget Toolkit [7] technology and can bypass firewalls and NATs. PECOLE uses separateJXTA-based MulticastSocket [19] for streaming audio, video and other multimedia data.Because of platform and transport independent features of JXTA, as well as our systemimplementation with JAVA based shared browser, it can be used in any machine and overany network environment. Furthermore, we adopted JXTA’s flexible, scalable and securegroup management system.

The next section discusses some existing related works in the area of distributedmultimedia collaborative system. Section 3 describes the architecture and design ofPECOLE, the multimedia collaborative environment we developed, along with its logicallayers, and the components of each layer. Software design is discussed in Section 4 with thehelp of standard UML notations. In Section 5, implementation details of the proposedPECOLE are given. Performance evaluation based on our test environment and results isgiven in Section 6. Section 7 concludes the work and gives the view of our future work.

2 Related work

Most shared applications [8, 21, 22, 26, 29] use the client-server model. Within this model,the server is usually very complex and heavy since it is, among others, responsible forgroup management, which sometimes becomes a communication bottleneck. This is due tothe fact that all the data exchanged among the group members is mediated by the server. Tosolve the above problem, application sharing needs to adopt a pure P2P architecture wherethere is no centralized server. A group member or a node, called a peer, dynamically findsother peers via distributed searching and directly exchanges data with other peers.

The work proposed by El Saddik et al. [8] describes the design and implementation of sometransparent synchronous client-server based collaborative tools facilitating the followingaspects: (1) latecomer support for Java applications, Java applets and JMF players, (2) clientsynchronization to minimize data transmission latency; and (3) lightweight multi-sessionsupport to allow multiple groups to collaborate simultaneously. The proposed work usessimilar user management capabilities as the one presented in this paper.

Kawashima and Ma [20] developed a collaborative tool called TOMSCOP, which isbased on the elementary peer group services offered by the JXTA general framework.TOMSCOP provides four types of services: synchronous message transportation, peer roomadministration, peer communication support and application space management. However,TOMSCOP suffers from inefficient pipe advertisement problems and it takes a long time.Also there are some features that are not available in TOMSOP such as multilingual

Multimed Tools Appl (2008) 39:353–377 355

collaboration, and multipoint-to-multipoint audio/video conferencing. In [3] a modifiedversion of the TOMSCOP architecture was proposed, which supports a multi operatingsystem. However, it still lacks the audio/visual communication and the multilingualbrowsing facilities. Similarly, Ma et al. [23] propose a distributed synchronouscollaborative system. They use JAVA and JXTA to build the system. But their proposeddesign methodology suffers from long peer search processes, variable and relatively largemessage transfer delays and they experience synchronization problems among peers.

Agudelo et al. [1] propose a simulated collaborative virtual environment for distanceeducation where they develop a virtual classroom and facilitate the collaboration amongteachers and students through video conferencing and slide sharing in the virtualenvironment. However, their approached prototype which is only implemented in thecampus LAN, does not consider the low bandwidth network, and may not be suitable forfully distributed networks. In fact, Agudelo et al. [1] did not address the issue ofmultilingual and multipoint-to-multipoint audio/video conferencing systems that we believeare vital in today’s collaborative environments.

In general, many collaborative environments and systems have been proposed, each ofwhich has several capabilities and advantages, however, to the best of our knowledge, thereis no collaborative environment that supports both multilingual shared browsing where eachpeer receives its content it is browsing in its language of preference and multipoint-to-multipoint video conferencing in a P2P fashion.

3 Proposed layered architecture

The high level architecture of the proposed PECOLE system is shown in Fig. 2. Every peerhas four logical layers: (1) collaborative application (CA); (2) workspace manager (WM);(3) session manager (SM); and (4) communication manager (CM). All these four layersoperate on top of the JXTA platform, which hides the physical network underneath it. Wenext describe the services offered by each layer.

3.1 Collaborative application (CA) layer

The CA layer hosts the PECOLE collaborative applications and any application-specificprotocols. Among the designed and developed applications are multipoint-to-multipointaudio/video conferencing, multilingual collaboration with telepointer, shared browsing, andchat. Events generated at the CA layer are of two types: (a) local and (b) remote. Localevents are handled locally by the collaborative applications and are sent directly to the localapplication layer for reconstructing the local GUI, and therefore do not need to be sent toother peers. Remote events encompass all such events and messages that should be sent toremote peers in the same session in order to keep them synchronized. That means, remoteevents are passed to the lower layers for transmission to the remote peers. This happens inthe case of a collaborative session where a session chair wants to send, e.g., the URLs ofthe web site she is navigating.

3.2 Workspace manager (WM) layer

Aworkspace is a collection of objects, such as text, graphs, and images, that belong to someshared application as well as having the tools necessary to access and manipulate theseobjects. When multiple users collaborate by jointly manipulating a shared object, the need


for synchronization arises. Users can synchronize their workspaces by exchanging events.The WM layer is responsible for intercepting user events and passing them to theunderlying session manager (SM) layer which in turn broadcasts them to all participantsbelonging to the same session. On the receiver side, the WM layer is responsible forreceiving remote events from the SM layer and dispatching them to the appropriate sharedapplications. This can be designed and implemented using JXTA propagate pipes [25].Propagate pipes connect one output pipe to multiple input pipes. Messages flow from theoutput pipe (the propagation source) into the input pipes in the same peer group.

3.3 Session manager (SM) layer

Users collaborating in a shared workspace are said to form a session. A session is a periodof synchronous interaction. In every active session, one user is identified as the sessionchairman or moderator. The moderator manages the session by invoking appropriate toolsand coordinating participants in the session.

The SM layer is responsible for establishing, managing, and terminating sessions amongpeers. It is also responsible for floor and telepointer control and for maintaining a list ofactual participants in every session. The list is used to broadcast session messages to allparticipants using the services of the underlying CM layer.

Our session management system works as follows. The initiating user (session chairman/moderator) starts a new session. Users who want to participate in the session must first join thesession. There are two ways to find a session: a user can find a session by browsing a list ofcurrently active sessions; or a user knows in priori that the session will be taking place andexplicitly requests a join command. Once a user knows the session name, he can attempt to join it.

Similar to [26, 20], PECOLE comes with a standard moderation system that facilitates theonline peers to use the moderator/audience role while they are collaboratively working on amultimedia document. This moderator role can be thought of as a token in a token ring network,

Fig. 2 PECOLE high level architecture


in which the node/peer having the token is the peer allowed to send data to other peers.PECOLE’s applications, running in a collaborative session, fall into one of the following twocategories: (1) moderated, including telepointer, shared browsing, multilingual collaboration and(2) non-moderated, including chat and audio/video conferencing. Moderated applications cannotbe initiated unless the pre-defined session chair logs in the session while peers can launch anduse the non-moderated applications any time. For example, the peers can send chat messagesand see each other through video conferencing without any moderator while shared browsingcannot be conducted unless the session chair logs in the session. However, while the session isgoing on, moderatorship can be requested by any peer in the session and the requesting peermight receive the moderatorship privilege if the current moderator releases the lock. Above all,the session moderator has the super privilege to discard or take away this temporary privilege,which was assigned to other peers, at any given moment in time if she feels the need to do so.

3.4 Communication manager (CM) layer

The CM layer provides the services necessary for message transportation between peers. It isimplemented using JXTAMulticastSockets. This layer facilitates the initial connection to JXTAnetwork and the maintenance of this connection throughout the session’s lifetime. This layercoordinates various modules such as Chat Manager, the Session Manager, and the GUIcomponents. The CM layer provides reliable transportation of messages using sockets. The CMlayer creates JXTA sockets over the JXTA pipes, which provide the transportation of messagesbetween peers. It also helps in the creation and joining of peer groups by creating, posting andfinding JXTA advertisements for groups or peers. Furthermore, the CM layer receives requestsfrom the other components to send chat messages or multimedia content. On the receiving end,the CM layer gets the message and passes it back to the appropriate component for display orprocessing. Processing HTTP requests and responses is also the responsibility of the CM layer.

4 PECOLE software design

PECOLE software design is based on the Java binding of the JXTA protocol suite. Giventhat the low level communication functions are handled using JXTA, it seems natural to usethe Eclipse Java SWT library [7] or Java SWING components for the Graphical UserInterface (GUI). In this project we decided to use the SWT library, since it offers graphicalcomponents that embed standard web browser characteristics such as Internet Explorer andMozilla in a Java virtual environment. A high level view of the main functionalitiesprovided by PECOLE is depicted in Fig. 3a, which is realized by standard UML 2.0 usecase diagram. As seen in Fig. 3a, PECOLE has two external actors: (a) local peer and (b)remote peers. By local peer we mean any peer of a given session while by remote peers wemean the rest of the peers in that collaborative session. As shown in the use case diagram,PECOLE provides the following key functionalities:

1. Login and connect to the JXTA overlay network using JXTA communication servicesand protocols

2. Discover existing JXTA peers and sessions that are defined in the same domain3. Create, Join, and Leave sessions4. Collaborative web browsing5. Collaborative group chatting6. Collaborative audio/video conferencing7. Multilingual collaboration


8. Moderation for floor control and9. Shared telepointer demonstration

Figure 3b shows the PECOLE jar file, the main package of the system that needs to runseveral packages including the main JAVA standard libraries included in the Java virtualmachine, the JMF library, the graphical library of SWT, and the JXTA library. As we willsee in the remainder of this paper, PECOLE’s multipoint-to-multipoint audio/videoconferencing feature is implemented using JMF package. The shared browser isimplemented using SWT package. We strive to design our application in such a way thatthe GUI and the workspace management logic are decoupled from the JXTAcommunication logic. This increases code modularity and clarity.

In order to provide a comprehensive idea of PECOLE software design, we follow twoapproaches. The first is the architectural design where we extend the high level systemarchitecture shown in Fig. 2 and show the architecture of each subsystem (we assume eachapplication is a subsystem), which shows the basic components of each application and howthey communicate with each other. The second one is the mechanistic design where we showthe classes inside some of the important components and how they are related to each other.

4.1 Architectural design of sub-systems

4.1.1 Audio/Video conferencing

Although few video applications are developed over JXTA overlay network including [28],no multipoint-to-multipoint audio/video conferencing system have been developed basedon JXTA so far. Four main technical components are necessary to provide a basic set ofconferencing services [10]. These components are: a user interface, efficient coder–decoders (CODEC) for audio and video, efficient networking support, and a set ofconference control functions. The logical relationship among these components defines thearchitecture of such a conferencing system.

Figure 4 displays the architecture of PECOLE audio/video conferencing system. It islargely consistent with several architectures proposed in the literature of Gong [10] andWilcox [30]. PECOLE uses separate JXTA sockets for audio and video to make thecommunication faster.

The video message is created in a three step process. First of all, the video framesgrabbed by a web camera using Java Media Framework (JMF) utility libraries [11] are sentto an H.263 CODEC [16], which generates the compressed objects. This compressiontechnique is very important for the low bandwidth network. Secondly, the compressedvideo frame objects need to be converted to byte arrays in order to be able to send themthrough JXTAOutputStream.

Finally, this stream is passed through JXTA sockets which convert the byte array tooutput streams that eventually use the JXTA network for transportation. To send the videostream to N (including the sender peer) number of peers simultaneously, PECOLE usesJXTAMulticastSocket to multicast the video stream. The sender peer only opens oneJXTAMulticastSocket to send video stream to N number of peers. At the receiver end, thededicated JXTAMulticastSocket receives the stream and generates byte array, which in turnis passed to the transformation engine to reconstruct the compressed video object. Beforeplaying the video by the player plug in, the image panel receives the compressed videoframes sent by the H.263 decoder after constructing the video frames.


Figure 4 also shows the multipoint-to-multipoint audio conferencing architecture ofPECOLE. As the figure portrays, the audio data is first captured by the audio data line fromthe audio capture device, such as a microphone. It is then received and stored in the audiobuffer, constructed as a special audio object, and sent as byte arrays to a JXTAOutputStream unit. Another dedicated JXTAMulticastSocket then streams the audio datato JXTA network. The following code snippet shows the audio acquisition format (in Java)used in PECOLE.

Fig. 3 a Main use case diagram. b Package diagram


As shown in Fig. 5, we used a PCM audio format with a sample rate of 8,000 Hz, 8 bits/sample, 1 byte in each frame, and 1 frame/second. They are stored in little-endian style. Onthe receiver end, the receiving peer’s dedicated JXTAMulticast audio socket tunnels thestream into a JXTA InputStream which converts the stream to byte array. The byte arraysare then passed to the transform unit for the audio data conversion that is processed by theaudio data line to supply the audio data to the audio play device.

4.1.2 Multilingual collaboration

The proposed PECOLE system supports multilingual collaboration. That means severalpeers with different spoken and written languages each (English, French, German, etc.) cancollaboratively browse the web or share a document in their own or preferred language.This capability can be implemented either by using a static or dynamic procedure. In theformer (static) case, the content of a document must exist a-priory in several languages. Forinstance, this is the case at the University of Ottawa, where most of the courses are taught inboth English and French. Multilingual content exists also on the BBC [4] or EURONEWS[9] web site, which we also used in our tests. In the later case (dynamic translation), thecontent exists only in one language and a basic language translation service is used todynamically translate the content based on the language of preference of the peer. For every

Fig. 4 PECOLE multipoint-to-multipoint audio/video conferencing architecture

Fig. 5 PECOLE audio acquisi-tion format


URL that the audience peer receives from the moderator, the peer requests the translationengine to translate the content. The translation engine then translates the web content, ifnecessary, depending on each peer’s language preference and forwards the content to thecorresponding peer. Figure 6 shows the multilingual collaboration architecture that we usedin PECOLE.

4.1.3 Chat

PECOLE adopts a standard P2P based chat style where users can select and enter roomsand communicate with text messages [24]. There is no chat server service at all, no centralpeer. All clients run independently, listening for chat messages and sending them to eachother. JXTA discovery provides the capability that makes it possible. Like any P2P system,PECOLE provides existing rooms for chatting and if needed, any peer acting as systemadministrator can also create new rooms so that others can join them. The key here is thatall the people that are chatting with each other are part of the same session. In principle allthey have to know about the session is the session name.

4.1.4 Telepointer

Telepointers are replicated cursors that track the location and interactive movement of apeer’s mouse pointer and replay it to all the peers attending the session of a groupwareapplication. Telepointers are one of the most useful elements of real-time groupware. Theyare simple to implement, but provide embodiment, awareness, and gestural communication.However, telepointers often suffer from severe performance problems on real-worldnetworks (Internet). Although performance issues have been considered by a few computersupported collaborative work (CSCW) researchers [6, 12, 14], there are very few currently

Fig. 6 Multilingual collaboration architecture


available implementations in P2P network. We propose a telepointer implementationstrategy with the aid of SWT technology.

The telepointer function provides two modes, moderator mode and audience mode, tocontrol whose cursor will be displayed in the shared browser among all the group membersof any session. When a peer having the moderator privilege uses the telepointer, aTelepointerMessage object is constructed upon moving the cursor. The TelepointerMessageobject contains the X and Y coordinates of the moderator’s cursor. Then the object is passedto the workspace layer, which is then multicasted by the session layer and transportedthrough the communication layer to all the session’s participants. When the sessionmembers receive the telepointer object, they reconstruct the remote event and dispatch it tothe right window GUI component.

4.2 Mechanistic design

In the mechanistic design we group the important Java classes according to theirfunctionalities, which results in the audio/video conferencing class diagram, the applicationlayer class diagram, the communication layer class diagram, the utilities class diagram, andthe message class diagram. Now we will briefly describe each of the class diagrams.

Since PECOLE enables the multipoint-to-multipoint audio/video conferencing feature, aset of instances of the classes depicted in Fig. 7a is created for every connection made to apeer. If a peer requests an audio/video conferencing session to be started with another peerthen two threads are launched. The first one will be serving the video channel and thesecond one the audio channel. ClientServerVideoFrame is the main video class that handlesthe sending/receiving and encoding/decoding of video frames at the application layer. Italso enables the user to see his video before sending it and receiving the other people’svideos in a multi panel video window. AudioStreamer is the class responsible for the audiopart of the audio/video conferencing session. Both classes initiate the creation of the threadsmentioned earlier.

Figure 7b depicts the application layer class diagram of PECOLE. The Collaboration-Window class represents the main SWT window for the peer to interact with thecollaboration sessions, to view the inputs and to create outputs. The LauncherFrame isthe frame window for creating new collaboration sessions. The CBListener andMyGlassPane classes are used to provide telepointer capability to the system.

Figure 8a shows the communication layer ‘CM’ class diagram. The main class in thisdiagram is CommunicationManager. Its main role is to connect the peers in the virtual P2PJXTA network, and to create a collaboration server and JXTAMulticastSockets needed fordifferent multimedia applications. Requests arrive as a JXTA message. ReaderThread is thethread launched as a service for listening to the other peer’s messages. Another important threadis ConnectionServerThread. This thread keeps watching the server socket. As other peersconnect to the socket, this class creates a new connection session. For every connection a peercreates, there is a special manager called SenderReceiverConnection. It has the core code thatstarts a collaborative connection and then handles the send/receive on the created I/O streams.The CollaborationSendListener is the interface that links the GUI to the session. It has a sendmethod that is used to pass theMessageObjects to the session manager for transmission. Finally,the ConnectionListener interface announces that a new socket connection was created.

PECOLE uses some utility classes (see Fig. 8b). The MD5ID class creates pipe ID andgroup ID from 128-bit MD5 Hashes. The PeerGroupTool is a class of utility methods thatcreate the peer group. Utility class facilitates in configuring the buffer size, timeout etc.parameters.


Fig. 7 a Audio/video conferencing class diagram of PECOLE. b PECOLE application layer class diagram


All the communication in PECOLE is carried out in the form of messages (see Fig. 9).ChatMsg message is the data sent between peers as a chat message. TelepointerMessagecontains the X, Y co-ordinates of the moderator’s mouse that are sent to all the audiences.URLTypingMessage refers to the characters typed in the URL text field of the shared

Fig. 8 a Communication layer class diagram. b Utilities class diagram


browser by the moderator, which is synchronously sent to all the audiences. RemotePeer-NameMessage is a handshake message sent by a peer to establish a connection with anotherpeer. If the handshake succeeds, the second peer sends ConnectionAcceptedMessage to therequesting peer. If the handshake is unsuccessful, the second peer sends ConnectionRefu-sedMessage to the requesting peer. GoodByeMessage is sent to all the peers of the samesession when a peer leaves a session. ModeratorMessage consists of two distinct parts. Aresponse message is sent by the moderator to the audience who is requesting themoderator’s privilege. A request message is sent by any audience to the moderator askingfor the moderator privilege. MSGAudioStream is the audio message sent between two peers.

5 User interfaces

There are several applications and features integrated with the current version of PECOLE.These are shared browsing, multilingual collaboration, telepointer, moderation, multipoint-to-multipoint audio/video conferencing, and chat. The following sections provide theimplementation of each of the applications mentioned above.

PECOLE is implemented with the Eclipse project’s Java-based SWT technology and canextend the functionalities of the Operating System’s (OS) default browser. If the defaultbrowser is Internet Explorer (IE), then PECOLE can extend the properties of IE in additionto its own sets of browser properties. The same is true for any underlying web browser,irrespective of the OS in which PECOLE runs [7]. So, it supports javascript, vbscript, xml,plugins, applet, external viewers etc. This property helps sharing, not only with HTMLdocuments using different scripts, but also with sharing video and audio, even whileplaying them in an external player.

Fig. 9 Messages class diagram


We now briefly introduce some of the GUI functionalities of PECOLE as shown inFig. 10. Label 1 shows the basic web content area where the body of a document appearswhile Label 2 refers to the area where users type the URL of a resource. Label 3, 4 and 5indicates browser’s ‘Go’, ‘Back’ and ‘Home’ buttons respectively. In order to request amoderatorship, a peer has to click on the ‘Moderator Request’ button as shown by Label 6.Label 7 shows the ‘Exit’ button and Label 8 lists the number of peers in the session whileLabel 9 shows the current session name. Chat messages appear in the area shown by Label10. Label 11 indicates the button group ‘Search’ helps in finding other peers dynamically.By clicking on ‘Join A Peer’ one can initiate a direct one to one collaboration. Label 12shows a pop up window that appears to all other peers when any peer leaves a session.

As discussed above, peers can browse the web collaboratively, each in his preferredlanguage. We take a bilingual classroom, English and French, as a proof of concept ofmultilingual collaboration. In this scenario, we assume that the students and the teacher fallinto two language groups, English and French. The teacher has the moderator privilege thatstarts the session with his language of preference while the students receive the samecontent with their language of preference. The moderator has control over the browser.Figure 11 shows two collaborating peers, one viewing the content in English, and the otherin French, while they are collaboratively browsing an anatomy lecture note.

The shared telepointer is intended to provide awareness information of the moderator’sinteractions by showing the movement of his cursor (red pointers in Fig. 11). In themoderator mode, the captured cursor position will be transmitted via JXTAMulticastSocketto all other participants of the same session.

Fig. 10 PECOLE graphical user interface


When a peer starts PECOLE and tries to join a session, the system, in order to supportthe tele-conferencing capability, first searches for the necessary audio and video hardware(such as a web camera, a microphone or speakers). If a device is missing, PECOLE warnsthe peer to mount the specific hardware. If the system passes the hardware test successfully,then the peer sees the audio/video interface. The numbers of audio and video interfacesdepend on the number of peers in the session. Although the underlying transport protocoluses a multicasting channel, any peer can specifically choose to multicast her video and/oraudio stream to any participant in a session. At the upper end, she can stream the audio and/or video streams to all the peers in the session. If every peer follows the same scenario, theyform a multipoint-to-multipoint audio/video conferencing session. Based on this fact, anypeer has the choice, to stream audio and block video, or vice versa, or send both to anynumber of users or block sending streams. The top timer panel at the bottom end of eachvideo interface of Fig. 12a is the video timer while the bottom one is audio timer.

The timer shows the time elapsed in the conferencing session. Figure 12b shows amoderated-session time message communication where a peer asks for permission from thecurrent moderator. In one case the current moderator refuses to handover moderatorship andin the other case he grants the privilege to the requesting peer.

6 Testing and result

We tested PECOLE by connecting the peers to each other in real-time from differentregions including Germany and different places in Canada (Ottawa and Montreal).

Fig. 11 Telepointer and multilingual collaboration demonstration, the top browser shows the content inFrench while the bottom browser presents the same content in English


Fig. 12 a Five (5) peers in an audio/video conferencing session. b Moderation capabilities in PECOLE


Figure 13 depicts the PECOLE test environment that will be discussed in the following.The test venues were:

Ottawa, Canada: Multimedia Communication Research Laboratory, under strict firewall,three peers in the laboratory running Windows XP/2000, network: Ethernet LANHannover, Germany: Under NAT, two peers in an internet café connected through ashared 11Mbps wireless router which in turn is connected to ADSL, the operatingsystem is Windows XP/2000, network: Ethernet LANMontreal, Canada: Dial up user connected to the Internet Service Provider through a56 Kbps modem. The operating system is Windows XP

To evaluate a fully distributed P2P-based collaborative system, peer discovery time isone of the most crucial factors because it is a basis for group/session formation. Once thegroup is formed, the next factor that affects the communication is the application toapplication message communication delay. A third element that also qualifies a multimediadistributed system is jitter, which is the difference in delay between two successivemessages or packets. Here, by the notion of jitter, we mean the delay between twoconsecutive messages arriving at the application layer after being received by another peer.

Fig. 13 PECOLE test environment


Finally, as the audio and video is a real-time application, the delay in frames is an importantevaluation criterion to measure the quality of experience (QoE) as defined in [2, 15]. Becausewe did not implement any tightly coupled time synchronization protocol such as NTP, for thesake of delay-metric evaluation of PECOLE, we employed an acknowledgement based roundtrip delay for the multicasting channel. However, PECOLE does not use acknowledgementfor any of its applications. In addition, temporal synchronization among the streams such asaudio, video, and telepointer is left for future work of PECOLE. Due to its pure P2Pimplementation strategy, the performance of PECOLE has not noticeably changed the numberof peers that join or leave any particular session, thereby making PECOLE fault tolerant.

To better evaluate the proposed system and to calculate the communication delay of thedifferent applications, we measured the data in different times of day including day andnight. Communication delay depends mostly on Internet traffic, which is variablethroughout a day. The following items and/or packages were installed and configured forthe smooth startup of PECOLE.

& JXTA: Jar files that come with the stable version 2.3.3 released in 03/14/2005& Peer configuration: Simple peer using a relay (as the peer is behind firewall/NAT)& Transport protocol: TCP/UDP and HTTP (when the peer is behind firewall/NAT)& Streaming audio and video: JMF 2.1.1e& Virtual machine: Java Virtual Machine that comes with JDK 1.5& System distribution and server processing in each peer: JNLP 1.5 and Java Web

Start [17] to be able to start the collaborative application from a web browserPECOLE is a Java-based application; consequently a peer only needs a copy of the

distribution JAR file to be downloaded on his/her machine to start the application

6.1 Peer discovery time

Peer discovery time is the time that is required to discover a peer of the same session beforestarting the collaboration. Although JXTA provides the basic peer discovery facility, weimplemented a novel peer discovery algorithm on top of the basic facility. We tested peerdiscovery time extensively in different portion of a day for about 4 months. According tothe test data we have found so far, the peer discovery time varies based on two situations;whether the peer is behind a firewall and/or NAT or whether it is inside the same LAN. Ittook approximately 30 s to 4 min to discover a peer when the peer was behind firewall orNAT. In this situation, peer discovery time is dependent on the traffic around the externalrelay peer (one of the SUN Microsystems relay peers) itself and thus, the time variesbetween 30 s to 4 min. For the second situation, where all the peers were inside the sameLAN, the peer discovery time was negligible.

6.2 Average message communication delay

Figure 14a shows the average application to application layer round trip delay among peersfor different PECOLE applications. We tested PECOLE with three, four and five users indifferent instances; however the average delay was almost the same. We took 1,000instances of delay for each of the applications and depict only the average delay. It showsthat shared browsing suffers the highest delay which is approximately 104.35 ms.

The reason is that each peer’s browser needs to download the web content that iscurrently viewed by the moderator by sending an HTTP request to the web server where theweb content is located. So, in addition to URL message communication delay, the web


content loading time is also added. It makes the delay higher in comparison with othertypes of application delays. A similar type of test was conducted for other applications (seeFig. 14a). According to the data we found, telepointer messages took approximately78.54 ms while moderation messages required an average delay of 80.567 ms. Chat datatook the least time, approximately 67.46 ms. The reason for this small delay (for chat,telepointer and moderation messages) in comparison with that of the web request is that inthese cases, the update messages are sent directly between the peers and therefore, no extradelay of requesting web content from a web server is required.

6.3 Application layer to application layer jitter

Figure 14b shows the average application layer to application layer jitter which we calculatein the following way: we define the jitter between two messages M1 and M2, as follows:

Jitter Jið Þ¼ R2 � S2ð Þ � R1 � S1ð Þ ð1Þwhere R refers to the receiving time of an acknowledgement message and S refers to thesending time of the timer when the message is just sent from the application layer of thelocal peer, which is destined towards a remote peer.

Now we get the

Average Jitter ¼PN�1

iJi

N � 1; where N ¼ total number of messages ¼ 1000 ð2Þ

The obtained data show that the mean value of jitter for the shared browsing is still thehighest which is followed by moderator messages, telepointer messages, and chat messages.

6.4 Video frame transmission delay

We tested the video frame delay between application layer to application layer while three,four and five peers were in a multipoint-to-multipoint video conferencing session. Thefollowing is the specification of video frames we used for the test:

& Video: H.263 compliant& Resolution: 320×240,

Fig. 14 a Average application layer to application layer message round trip time. b Average applicationlayer to application layer jitter


& Frame rate: 15 fps& Bit rate: 50–56 kbps

We chose the bit rate so that a dial-up user can also take part in video conferencingsession using any 56 kbps modem. The test was also carried out at two different times ofday; during day time and during night time. In each case we took 11000 sample of videoframes as test samples. The video frame delay represents the average transmission delay ofsending a frame and receiving the response from all the peers of the group, taking intoconsideration that the frame travels from the application layer of one peer and reaches theapplication layer of other peers in the same session and finally the acknowledgementmessage again reaches the application layer of the sender. We call this delay applicationlayer to application layer round trip delay. The average round trip delay of five peers in avideo session during day time was the highest, marking approximately 91.3225 ms while atnight time it was approximately 90.4812 ms. In the case of four peers the delays were89.54252 ms and 89.1312 ms during day and night time respectively. For three peers, thedelay we found was 89.15663 ms during daytime while 90.56315 ms during night time.

Because the test results reflect the delay in terms of round trip delay, the end-to-enddelay will indeed be less than the delay for each case once we subtract the returning time ofthe trip. The returning time is the time required for the acknowledgement message of thevideo application from remote peers indicating that the frame is successfully received.

As suggested by Baldi and Ofek [2] and Steinmetz and Nahrstedt [27], the maximumtolerable end-to-end delay (including propagation) for natural hearing is 100 ms hence, themaximum delay for picture-frame display should also be 100 ms because both audio andvideo should be synchronized in real time, i.e.,

Processing delay (at sending peer) + network delay (at P2P network) + network re-synchronization delay + processing re-synchronization delay (at receiving peer) +processing delay (at receiving peer) ≤ 100 ms, which is in our case about 89 ms, as canbe seen above.

6.5 Scalability testing

PECOLE is based on JXTA and JXTA itself offers a scalable P2P network [13, 18]. Wetested the scalability of PECOLE by connecting to 15 peers in the same session. Somepeers joined, after a while some others left, and again some more joined. In this process, wetested PECOLE for 10 h. Within this evaluation time, all the applications of PECOLE suchas shared telepointer, shared browsing, multilingual collaboration etc. were tested and theyshowed similar performance and delay parameters as discussed above. The reason of thisscalability is described in detail in Section 4.1. For example, in the case of shared browsing,PECOLE just sends the URL of the moderator peer to all the audience peers and uponreceiving the URL, the audience peers simply download the browser content. Depending onthe physical location of the peers, an audience peer can even browse faster than themoderator peer.

6.6 Subjective evaluation

We tested the quality of experience of PECOLE among 20 students of the University ofOttawa. This includes both undergraduate and postgraduate students of diversified ethnicity,including male and female who had either fair, little or no knowledge about collaborativeapplications beforehand. Each time five students joined the collaboration, after the


collaboration they all took part in filling out the questionnaire. The participants had novisual impairments. Figure 15 shows the summary of the questionnaire:

Each question was ranked from 0, representing the least satisfaction, to 5, whichcorresponds to full satisfaction. Figure 15 shows the average weight scored for eachquestion. We did not take into consideration the time taken by each participant to performthe whole test as it varied from person to person based on his/her background. The standarddeviation is 0.71.

7 Conclusion and future work

In this paper we described the design and implementation of a synchronous collaborationenvironment, named PECOLE that supports several collaborative applications such asshared web browsing, chat, multipoint-to-multipoint audio/video conferencing, telepointeroperation, and multilingual collaboration. Our effort goes towards making services offeredby PECOLE ubiquitous with the aid of JXTA-based P2P framework. Compared to othersimilar solutions, our implementation has some significant features. To make thecommunication faster, PECOLE uses three separate Multicast sockets: one for audio, onefor video and one for control and/or data messages. Whenever any new peer joinsthe collaborative session, it automatically joins the multicasting group of the session. Theexisting peers of the session need not create any new communication channel for thelatecomer support thereby making the communication robust and scalable. To the best ofour knowledge, the multipoint-to-multipoint audio/video conferencing system and themultilingual collaboration that are introduced in this paper have not been implemented byany JXTA-based P2P system before. The audio/video streams can overcome firewalls andNAT’s. Adopting the multilingual architecture of PECOLE, any multilingual classroom cancollaborate in real-time.

Some important work still remains to be done. First, we intend to integrate some otherpopular collaborative applications with PECOLE such as shared document authoring. Weare also planning to incorporate new media such as haptic devices (for capturing touch) andsensor devices (for sensing smell) in our future endeavor of enriching PECOLE.

Fig. 15 Average weight scored for each of the eight questions


References

1. Agudelo A, Escobar L, Restrepo J, Quiroz A, Trefftz H (2004) A collaborative tool for synchronousdistance education. In: Proceedings of the 7th IASTED International Conference on Computers andAdvanced Technology in Education Kauai Hawaii. USA, August 2004, pp 438–443

2. Baldi M, Ofek Y (2000) End-to-end delay analysis of videoconferencing over packet-switched networks.IEEE/ACM Trans Netw 8:479–492

3. Barolli L (2006) M3PS: a multi-platform p2p system based on Jxta and Java. In: Proceedings of the 4thinternational symposium on principles and practice of programming in Java. Mannheim, Germany, pp 224–229

4. BBC (2006). http://www.bbc.co.uk/5. De Oliveira JC, Hosseini M, Shirmohammadi S, Malric F, Nourian S, El Saddik A, Georganas ND

(2003) Java multimedia telecollaboration. IEEE Multimed 10:18–296. Dyck J, Gutwin C, Subramanian S, Fedak C (2004) High-performance telepointers. In: Proceedings of

the ACM conference on computer-supported cooperative work, Chicago, IL, USA. ACM Press, NewYork, NY, pp 172–181

7. Eclipse Standard Widget Toolkit (SWT) (2006) http://www.eclipse.org/swt/8. El Saddik A, Yang D, Georganas ND (2006) Tools for transparent synchronous collaborative

environments. Multimed Tools Appl 33:217–2409. Euronews (2006) http://www.euronews.net/10. Gong F (1994) Multipoint audio and video control for packet-based multimedia conferencing. In:

Proceedings of the 2nd ACM international conference on multimedia. San Francisco, California, USA,October 1994. ACM Press, New York, NY, pp 425–432

11. Gordon R, Talley S (1999) Essential JMF: Java Media Framework. Prentice-Hall, New Jersey12. Gutwin C, Dyck J, Burkitt J (2003) Using Cursor Prediction to Smooth Telepointer Jitter. In: Proceedings of

the ACM SIGGROUP Conference on Supporting Group Work. Sanibel Island, Florida, USA. ACM Press,New York, NY, pp 294–301

13. Halepovic E, Deters R (2005) The JXTA performance model and evaluation. Future Gener Comput Syst21:377–390

14. Hayne S, Pendergast M, Greenberg S (1994) Implementing gesturing with cursors in group supportsystems. J Manage Inf Syst 10:43–62

15. Jain R (2004) Quality of experience. IEEE Multimed 11:95–9616. JMF (Java Media Framework) (2006) http://java.sun.com/products/java-media/jmf/17. JWS (Java Web Start) (2006) http://java.sun.com/products/javawebstart/18. JXTA Scalability (2006) http://platform.jxta.org/java/workinprogress/ScalabilityOverview.pdf19. JXTA Sockets (2006) http://p2psockets.jxta.org/20. Kawashima T, Ma J (2004) TOMSCOP—A synchronous P2P collaboration platform over JXTA. In:

Proceeding of the international workshop on multimedia network systems and applications(MNSA’2004), In: Conjunction with the 24th international conference on distributed computingsystems. Tokyo, Japan, March 2004, pp 85–90

21. Kim O, Kabore P, Favreau JP, Wahab HMA (1997) Issues in platform-independent support formultimedia desktop conferencing and application sharing. In: Proceeding of the 7th IFIP conference onhigh performance networking. White Plains, New York, USA, April 1997, pp 115–129

22. Kuhmünch C, Fuhrmann T, Schöppe G (1998) Java Teachware—the Java remote control tool and itsApplications. In: Proceeding of the EDMEDIA. Freiburg, Germany, June 1998, pp 70–75

23. Ma J, Shizuka M, Lee J, Huang R (2003) A P2P Groupware system with decentralized topology forsupporting synchronous collaborations. In: Proceedings of the international conference on Cyberworlds.Singapore, December 2003, pp 54–610

24. Margaritis M, Fidas C, Avouris N, Komis V (2003) A peer-to-peer architecture for synchronouscollaboration over low-bandwidth networks. In: Margaritis K, Pitas I (eds.) Proceedings of 9th PCI.Thessaloniki, Greece, November 2003, pp 231–242

25. Seigneur JM, Biegel G, Jensen CD (2003) P2P with JXTA-Java pipes. In: Proceedings of the 2ndinternational conference on principles and practice of programming in Java Kilkenny City, Ireland, June2003, pp 207–212

26. Shirmohammadi S, El Saddik A, Georganas ND, Steinmetz R (2003) JASMINE: a Java tool formultimedia collaboration on the Internet. Multimed Tools Appl 19:5–28

27. Steinmetz R, Nahrstedt K (2004) Multimedia systems. Springer, Berlin28. Tsuchiya T, Yoshinaga H, Koyanagi K (2004) STARCast: streaming collaboration architecture on

heterogeneous environment everywhere. In: Proceedings of the 2004 ACM workshop on next-generationresidential broadband challenges. October 2004, ACM Press, New York, NY, pp 57–62


http://www.bbc.co.uk/

http://www.eclipse.org/swt/

http://www.euronews.net/

http://java.sun.com/products/java-media/jmf/

http://java.sun.com/products/javawebstart/

http://platform.jxta.org/java/workinprogress/ScalabilityOverview.pdf

http://p2psockets.jxta.org/

29. Wahab HMA, Kabore P, Kim O, Favreau JP (1999) Replication management of application sharing formultimedia conferencing and collaboration. J Netw Inf Syst 2:63–74

30. Wilcox J (2000) Videoconferencing, the whole picture. Telecom Books, New York

Abdulmotaleb El Saddik (IEEE M’02-SM’03) is an associate professor at the School of InformationTechnology and Engineering (SITE) at the University of Ottawa. He is the director of the MultimediaCommunications Research Laboratory (MCRLab) and of the Information Technology Cluster, OntarioResearch Network on Electronic Commerce. He is the founder of IEEE International workshop on HapticAudio Visual Environments (HAVE) and a Distinguished IEEE Lecture. He is Editor of the InternationalJournal of Advanced Media and Communication and Associate Editor of the ACM Journal of EducationalResources in Computing (JERIC). He serves in the program committee (as chair) of several ACM and IEEEconferences and workshops related to multimedia communications and Haptics. He is a recipient of the“Premier’s Research Excellence Awards”.

Md. Abdur Rahman received a Bachelor degree in Electrical and Electronic Engineering from BangladeshUniversity of Engineering and Technology (BUET), Dhaka, Bangladesh, in 2000. He then joined thedepartment of Computer Science and Engineering of Khulna University of Engineering and Technology(KUET), Khulna, Bangladesh, in 2001 as a lecturer. He finished his Masters in Electrical Engineering fromthe University of Ottawa in 2005. He has been doing his Ph.D. in Electrical Engineering at the School ofInformation Technology and Engineering (SITE) of University of Ottawa since September 2005. Hisresearch areas are Multimedia Communication, Smart Sensors, Tele-surveillance and Distributed Networks.


Souhail Abdala earned his masters degree in Computer Science from the University of Ottawa in 2005. Hisresearch interests include peer to peer and collaborative environments. He is currently working as a seniorresearch with Canada Revenue Agency in Ottawa, Ontario.

Bogdan Solomon is a Masters student in Software Engineering at University of Ottawa. He received abachelor in Software Engineering from the University of Ottawa in 2007. His research area is related toautonomic computing.


Documents

PECOLE: P2P multimedia collaborative environment