PROVIDING PEER-TO-PEER FEATURES TO EXISTING

CLIENT

-SERVER CSCW SYSTEMS

Bernd Eßmann

Heinz Nixdorf Institute

University of Paderborn

Fürstenallee 11, 31102 Paderborn

Holger

Funke

University of Paderborn

Fürstenallee 11, 31102 Paderborn

Keywords:

CSCW, CSCL, Peer-to-Peer, JXTA, Mobile Computing, Spontaneous Collaboration.

Abstract:

Developers of classical client-server CSCW systems are facing a true dilemma: They created a working coop-

eration environment for many scenarios of cooperative work. Since users get independent from ﬁxed places by

using mobile devices interconnected by ad-hoc networks, the support of mobility becomes an important topic

of CSCW. Furthermore, while client-server architectures do not work well in dynamic networks, P2P systems

enter the ﬁeld of CSCW. But, is it a good approach to discard the well working client-server system in order

to implement a brand-new P2P system from scratch? Our approach is extending our CSCW platform step-by-

step with P2P abilities without loosing the advantages of client-server computing. This paper describes the

ﬁrst step of wrapping the RMI-based communication protocol into an industry standard P2P protocol called

JXTA.

1 INTRODUCTION

Client-server architectures found in classical CSCW

systems always need central servers available in the

used network infrastructure. But in mobility sup-

porting networks like Multi-hop Ad-hoc Networks

(MANETs) (Perkins, 2001) the network structure

changes dynamically and not predictable. The server

becomes an unreliable single point of failure because

its accessibility can not be guaranteed.

Thus Peer-to-Peer (P2P) architectures are used for

getting rid of this single points of failure. Our ap-

proach is to build an hybrid architecture without

obligatory dependencies between client-server and

P2P environment. Servers are used for providing the

cooperation environment when available and a P2P

architecture stands in for providing vital functional-

ity when not. This hybrid architecture provides the

advantages of both worlds for supporting the new

scenarios of mobile cooperation as well as classical

CSCW scenarios.

Our ﬁrst step to provide this hybrid cooperation

environment is extending our existing client-server

CSCW platform

open

sTeam with P2P features by en-

abling the stateful communication protocol to be used

in P2P communication. We will show that the basic

features of many classical CSCW platforms can be

transformed to work with P2P systems.

2 RELATED WORK

Speakeasy today known as Obje is a framework for

communication in heterogeneous network environ-

ments with several devices and applications (Edwards

et al., 2002b). The implemented approach is called re-

combinant computing, which means providing ﬁxed

domain-independent communication interfaces and

mobile code. Casca is an CSCW application using the

Speakeasy technology for cooperative work (Edwards

et al., 2002a). It allows discovering and selecting pos-

sible partners for collaborative work but provides no

semantic or object-oriented document structure like

virtual knowledge spaces.

Groove

is implemented as a P2P CSCW plat-

form. Users are enabled to work together in a shared

workspace. Looking at the architecture for synchro-

nizing the distributed workspaces Groove still re-

quires servers.

http://www.groove.net

271

Eßmann B. and Funke H. (2005).

PROVIDING PEER-TO-PEER FEATURES TO EXISTING CLIENT-SERVER CSCW SYSTEMS.

In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 271-274

DOI: 10.5220/0002528502710274

 SciTePress

Magi Enterprise

is a commercial product support-

ing teamwork by allowing communication and a fast

exchange of information. For this purpose, virtual

workspaces accessible for all team members are con-

structed by enabling Microsoft products with P2P

functionality.

Swifff

is a P2P framework providing the necessary

infrastructure for managing knowledge in dynamic

network environments (Eßmann et al., 2004). Since

its still in heavy research many mechanisms of sophis-

ticated CSCW environments like found in sTeam are

missing.

3 STEAM GOES P2P

On every client access to the sTeam server the pro-

prietary COAL protocol is used to transform the mes-

sages into byte sequences that are being sent to the

server. The server transforms the byte sequence into

a message which can be processed. The answer to the

client runs accordingly (Bopp, 2003). The main ob-

jective for enabling sTeam for P2P communication is

to transform this stateful protocol for stateless com-

munication as used in P2P networks.

The open-source project JXTA is a peer-to-peer-

platform consisting of a collection of different pro-

tocols. These protocols allow every device within a

network – a mobile phone, a PDA, a PC or a server

– to communicate and cooperate according to a P2P

network. JXTA intends to provide methods that en-

able every node in a network to gain access to all data,

contents and other nodes even when hid behind a ﬁre-

wall (Groth, 2002). All these methods are comprised

in an open code library (Wilson, 2002).

JXTA was choosen because it not just allows to

ﬁnd other peers in the network but also provides the

possibility to communicate in any heterogeneous net-

work. JXTA builds new virtual networks on the basis

of already existing physically. Figure 1 depicts such a

mapped network (Traversat et al., 2003).

Figure 1: Mapping in a JXTA network.

http://www.endeavors.com

http://swifff.upb.de

For communication purposes JXTA provides pipes.

Pipes are virtual channels for communication which

interconnect peers with each other even if there is no

direct physical connection. In this cases relay peers

are being applied. A pipe can be installed between

two peers (point-to-point) or between a single peer on

the one end a hole group of peers on the other end

(propagate). Communication that takes place by way

of pipes always runs asynchronously and unidirec-

tionally which makes pipes difﬁcult to use for clas-

sical CSCW systems. Thus, JXTA offers only basic

mechanisms for communcation purposes (Oaks et al.,

2002).

4 IMPLEMENTATION

To use the P2P extension of our implementation it is

necessary to establish a P2P network. The user can

activate the extension automatically while starting the

sTeam client. It is the possible to work in the classic

mode of sTeam or in the new mode with P2P func-

tions. When starting sTeam in P2P-mode methods

will be invoked setting up the P2P network. With

these methods the peers are able to search and ﬁnd

other peers of the same service type in their subnet.

To use these connections in the future, connections

are saved locally at each peer. During the setup of the

network these calls are used very often. Once the net-

work is established the frequency of these method in-

vocations will be reduced to decrease the trafﬁc over-

head. Thus a new P2P network is established which

is the base for the further process.

In the P2P network exist some peers with a spe-

cial role. In the setup phase they scan their neigh-

borhood for other peers in order to create a sTeam

P2P network. In difference to the normal peers they

own a direct connection to a sTeam server and adopt

the role of an agent peer, communicating between the

P2P network and the sTeam network. An agent peer

offers other peers a service to interact with the con-

nected sTeam server. The agent peer starts as a nor-

mal peer. Starting as a normal peer the peer recog-

nizes its speciﬁc role during the runtime. Because of

this self managing there is no matter to conﬁgure the

agent peer. Because the agent peer acts like a proxy

for the server, the server becomes a service in the P2P

network. An example of P2P network can be found in

ﬁgure 2.

The agent peer publishes its service by means of a

Peer-Discovery-Protocol via an according advertise-

ment that describes the respective service. As soon as

the peers looking for this advertisement ﬁnd it, they

can make use of it. This process is similar to any other

service in the JXTA network (Gradecki, 2002).

One important criterion of the implementation of

ICEIS 2005 - SOFTWARE AGENTS AND INTERNET COMPUTING

272

Figure 2: Network of sTeam-Peers.

the agent peer deals with the performance of the

mesage conversion.

The communication between the two different net-

works is the core element of the P2P extension. Some

methods are necessary for basic communication and

ﬁle transfer. Further methods translate the messages

between the two formats JXTA and COAL. All this

methods are provided in the classes JxtaMessage

and JxtaMessageWrapper.

Messages are exchanged between two different net-

work types. In both networks there are different for-

mats of messages available, on the one hand JXTA

messages and on the other COAL messages. There-

fore, the agent peer must be equipped with a facility

altering the different message types. We call this fa-

cility JxtaMessageWrapper. Our implementa-

tion has a minimal transformation overhead, so that

the transformation takes place very quickly. In fact,

the user will not notice any difference between the

delivery of a sTeam message in a classic client/server

system and the delivery of a JXTA message which has

to be transformed into a sTeam message on its way to

the server.

A message transmitted by the COAL protocol used

by sTeam is composed of a identiﬁer, the message

type, an object the message refers to and a number of

attributes. Additionally the message ist tagged with

a unique sequence number to assure the correct se-

quence of execution.

These message elements are extracted by the agent

peer and transfered in a JXTA compatible format. The

extracted elements generate the new JXTA-Message.

Figure 3 dispicts the way of a message from

the client to the server and back again. The

message is beeing generated as so far common

by the SteamConnector, MessageManager

and ServerConnection. After the mes-

sage is ﬁnalized, there is no need to transfer

it as a OutputStream to the server. In-

stead of this, the message will be passed to the

JxtaMessageWrapper which carries the JXTA

message to the P2P network. Arriving at the agent

peer, the Message will be retranslated to the COAL

format and delivered to the server. The back way

takes place analogous.

The basic idea connecting the sTeam network in

a fast way with the P2P network is wrapping COAL

into the JXTA protocol. This allows to transmit mes-

sages in both networks. As said, wrapping between

those protocols is applied by the agent peer. With

a closer look on both networks, the following three

problems appear:

• The communication of the COAL protocol in

sTeam is synchronous compared to the asynchro-

nous communication in JXTA networks.

• In JXTA the messages will arrive at the receiver in

no order, but in COAL the order is well deﬁnded.

• sTeam provides events to the clients which also

have to be processed in the correct order.

JXTA already provides a mechanism for synchro-

nous communication called bidirectional pipes. Un-

fortunately they provide a very slow performance. In

a simple measurement the factor 20 appeared as a av-

erage factor of slowdown in communication. Thus

we implemented a new message type basing on the

asynchronous concept of JXTA but extending it with

synchronous features.

The sender transmits a message on a standard pipe

and extends this message with a return address. On

this return address the sender waits for a acknowledg-

ment by the receiver. When receiving the message,

the receiver creates a new pipe with the return ad-

dress and sends a acknowledgment. This allows asyn-

chronous communication with two standard pipes in

a much faster way than with the bidirectional pipes.

To execute the messages in the right sequence in

sTeam, messages in COAL have a sequence num-

ber. This concept is retained in the JXTA-Network.

The wrapper of the COAL message uses the same se-

quence numbers as the COAL message; this way the

well deﬁned sequence of messages in sTeam is guar-

anteed.

The events send by the sTeam server are treated like

any sTeam message. Events arrive as COAL mes-

sages from server to agent peer and are wrapped as

JXTA messages and thus reach the peers. The se-

quence of the events is guaranteed by the same control

sequence as used for any COAL message.

The fast message conversion and the automatic

conﬁguration of the P2P functionality lead to a high

grade of transparency for the user. From the user’s

point of view it is of no importance whether he is

connected to the server directly or via a P2P connec-

tion. Yet, it is a great advantage that he can proﬁt by

the ﬂexibility offered by a P2P network. Although he

still needs access to a sTeam server he may connect

him through ﬁrewalls or from within networks with

network address translation (NAT) making him usu-

ally unreachable from outside. While COAL would

not allow this communication, this functionality is in-

herited from the JXTA protocol.

PROVIDING PEER-TO-PEER FEATURES TO EXISTING CLIENT-SERVER CSCW SYSTEMS

273

Figure 3: Message ﬂow between two different networks.

5 CONCLUSION

In this paper we presented our approach opening a

classical client-server CSCW system to the world of

P2P. The ﬁrst step of bringing P2P features to client-

server CSCW systems is allowing their clients to

communicate over P2P protocols. Classical CSCW

systems feature special characteristics which have to

be accounted to when wrapping them into stateless

P2P protocols. We presented solutions for carry-

ing the stateful communication of the client-server

CSCW system sTeam into the stateless communica-

tion of JXTA’s P2P world without loosing any func-

tionality. Neither the client nor the server had to be

changed in their core functionality.

Our future steps towards a fully mobility aware

cooperation environment will be to equip the clients

with basic features of the server. This will the clients

transforming to real peers which can run standalone

without any server in the network. The needed func-

tionality includes e. g. management functionalities

and a local repository for often needed cooperation

objects.

Although it might be a possible future developing

a sophisticated cooperation platform basing just on

P2P technologies, our approach allows providing an

always usable cooperation environment with evolving

features for new cooperation scenarios. Thus we pre-

sented the ﬁrst step toward an universal environment

providing the technical infrastructure for cooperation

support in everyday life situations.

ACKNOWLEDGEMENTS

Bernd Eßmann is member of the postgraduate pro-

gram 776 "Automatic Conﬁguration in Open Sys-

tems" funded by the German Research Foundation

(DFG) and the Heinz Nixdorf Institute.

REFERENCES

Bopp, T. (2003). steam server documentation.

http://www.open-steam.org/Dokumente/docs/-

Programer_Documentation.pdf (31.01.2005).

Edwards, W. K., Newman, M. W., Sedivy, J. Z., Smith, T. F.,

Balfanz, D., Smetters, D. K., Wong, H. C., and Izadi,

S. (2002a). Using speakeasy for ad hoc peer-to-peer

collaboration. In conference on Computer Supported

Cooperative Work (CSCW’02), pages 256–265, New

Orlando, Louisiana, USA. ACM Press, New York,

NY, USA.

Edwards, W. K., Newman, M. W., Sedivy, J. Z., Smith,

T. F., and Izadi, S. (2002b). Challenge: Recombi-

nant computing and the speakeasy approach. In Inter-

national Conference on Mobile Computing and Net-

working (MOBICOM’02), pages 279–286, Atlanta,

Georgia, USA. ACM Press, New York, NY, USA.

Eßmann, B., Hampel, T., and Slawik, J. (2004). A jxta-

based framework for mobile cooperation in distributed

knowledge spaces. In Karagianis, D. and Reimer, U.,

editors, 5th International Conference on Practical As-

pects of Knowledge Management (PAKM’04), Lecture

Notes in Artiﬁcial Intelligence, pages 11–22, Vienna,

Austria. Springer Verlag.

Gradecki, J. D., editor (2002). Mastering JXTA: Building

Java Peer-to-Peer Applications. Wiley Publishings,

Indianapolis, USA.

Groth, T. (2002). Project jxta. In Schoder, D., Fis-

chbach, K., and Teichmann, R., editors, Peer-to-Peer.

Springer-Verlag, Berlin, Deutschland.

Oaks, S., Traversat, B., and Gong, L., editors (2002). JXTA

in a Nutshell. O’ Reilly, Sebastopol, USA.

Perkins, C. E. (2001). Ad Hoc Networking. Addison-

Wesley, Boston, USA.

Traversat, B., Arora, A., Abdelaziz, M., Duigou, M., Hay-

wood, C., Hugly, J.-C., Pouyoul, E., and Yeager, B.

(2003). Project jxta 2.0 super-peer virtual network.

Wilson, B. J., editor (2002). JXTA. New Riders, Indianapo-

lis, USA.

ICEIS 2005 - SOFTWARE AGENTS AND INTERNET COMPUTING

274