FUTURE COLLABORATIVE SYSTEMS BETWEEN PEER-TO-PEER

AND MASSIVE MULTIPLAYER ONLINE GAMES

Markus Heberling, Robert Hinn, Thomas Bopp

Department of Computer Science, University of Paderborn, Fuerstenallee 11, 33102 Paderborn, Germany

Thorsten Hampel

Department of Knowledge and Business Engineering, University of Vienna, Rathausstr. 19/9, A-1010 Vienna, Austria

Keywords:

P2P, DHT, CSCW, software architecture.

Abstract:

Most current CSCW architectures rely on a central server and offer only limited scalability. With the emer-

gence of distributed hash tables as a comprehensive peer-to-peer infrastructure a wealth of new applications

can be developed. In this paper we propose a new DHT-based CSCW architecture, inspired by modern mas-

sive multiplayer online games architectures, using existing systems and technologies. The resulting CSCW

overlay network offers both robustness against network failures and scalability to support large numbers of

users simultaneously.

1 INTRODUCTION

Today’s collaborative systems are mainly based on

client-server based architectures. People interact

over various synchronous clients (chat, shared white-

boards, voice chat etc.) or asynchronous, typically

web-based, clients with a central server. Naturally re-

sulting out of the architecture model’s limitations, its

scalability is limited to a certain degree. This comes

especially into the focus if larger number of users in-

teract with a high density of user interaction. As an-

other matter of fact single-server CSCW-architectures

are also suffering the bottleneck of single server archi-

tecture regarding the question of security and stability.

A single server coordinating, organizing and being the

persistence layer for a number of clients forming a

collaborative system is the critical component in any

client-server-based CSCW-system.

Having these limitations in mind a close solu-

tion may be to apply multi-server or peer-to-peer

approaches to collaborative systems. Multi-server

CSCW-architectures are a difﬁcult to implement ar-

chitectural model, as collaborative systems are highly

interactive systems, where users move from one

server to another, share documents over the borders

of a single server and build (link) structures of media-

content from one server to another. All these technical

behaviours should be hidden from the user, e.g. user

transparency in a server-spanning way of interaction

is an important issue. This high degree of user inter-

action makes replicated architectures, such as a dis-

tributed database approach, which is typical for large

web-based systems, the wrong solution.

On the other hand modern peer-to-peer-

architectures can be identiﬁed as an interesting

alternative. They do not need a dedicated central

server, nor are they limited to typical problems of

scalability. Today’s successful P2P-architectures

(e.g. having Napster or the Groove toolkit in mind)

at ﬁrst can be described as hybrid client-server and

P2P-architectures (even Napster needs central servers

for sharing index-ﬁles for coordinating the peer-to-

peer connections). Therefore, so called superpeers

(Mizrak et al., 2003) serve different functions such as

providing persistency of some parts of the distributed

system or are able to guarantee for some security

issues when setting up a trustable CSCW-system.

Existing peer-to-peer architectures, such as dis-

tributed hash tables (Rhea et al., 2005; Rowstron and

Druschel, 2001b) can provide the basis for highly

interactive collaborative systems.What we get is a

highly scalable distributed persistence layer, where

objects are distributed over the clients and objects

may be distributed with a certain replication fac-

tor (unavailable peers, e.g. peers falling out of the

network, do not endanger the integrity of the net-

340

Heberling M., Hinn R., Bopp T. and Hampel T. (2007).

FUTURE COLLABORATIVE SYSTEMS BETWEEN PEER-TO-PEER AND MASSIVE MULTIPLAYER ONLINE GAMES.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - ISAS, pages 340-346

DOI: 10.5220/0002384403400346

 SciTePress

work/collaborative systems.) What is missing are spe-

cial features of such architectures resulting out of the

collaborative scenarios of use (e.g. interactions of

users/clients are spanning several peers in a collab-

orative system). Therefore we are mainly not only

talking about a problem of setting up distributed per-

sistency layers in a peer-to-peer architecture, but also

dealing with server-spanning event management. Si-

multaneously, all other problems of collaborative ar-

chitectures, such as user and group management have

to be solved.

This paper presents a ﬁrst step towards a next gen-

eration of peer-to-peer-based collaborative systems.

Our main contribution is setting up a ﬁrst infrastruc-

ture out of existing distributed hash tables compo-

nents, which serves as a ﬁrst good basis for peer-to-

peer based collaborative systems.

We propose our architecture and prototype as

an open source solution based on Past and Pastry,

which we shaped along the needs of collaborative

systems. Secondly we present a ﬁrst demonstrator,

which shows the architecture’s scalability through a

massive multiplayer online game “snake” application.

Our architecture therefore has close relations to mas-

sive multiplayer online games (MMOGs) (a relation

which is in the tradition of our ﬁrst classical CSCW-

architectures based on multi user dungeons – MUDS).

MMOGs share many of the requirements of collabo-

rative systems and are in some degree even stronger

in their demand for security, e.g. the so called “cheat-

ing” – attacks of some peers/players against the in-

tegrity of the network/game.

2 DHT PEER-TO-PEER

NETWORK

Our approach for a peer-to-peer CSCW architecture is

based upon existing technologies of distributed hash

tables (DHT) for storage and communication, replac-

ing traditional database and communication layers.

Distributed hash tables store data on the distributed

nodes of a peer-to-peer network, providing greater

scalability and, given the use of redundant storage,

better robustness through the lack of a single point of

failure. We will present a peer-to-peer network based

on the Pastry overlay network with the extensions Past

for persistent storage within the network, and Scribe

for message passing and event distribution on the net-

work. In section 4 we will then use this network as a

basis for a peer-to-peer architecture suited for CSCW

The authors have long lasting expericences in the de-

sign of collaborative systems. (Bopp et al., 2006)

systems.

Pastry (Rowstron and Druschel, 2001a) is a ring-

based peer-to-peer overlay network. It provides ef-

ﬁcient algorithms for localizing objects within the

distributed hash table and for routing packets with

the network. It is completely decentralized and self-

organizing, inserting and removing nodes into the net-

work automatically, thus allowing for easy scalability.

Objects in Pastry are stored and referenced by a 128-

bit id in a circular logical address range. Objects are

stored on nodes with an id closest to the object’s id,

so that the hash function of Pastry can localize them

within a small number of hops. Nodes provide their

own routing tables to their logical neighbors and are

thus able to route network packets to the correct des-

tination. These routing tables are updated whenever

neighboring nodes leave the network, so that the net-

work reorganizes itself automatically. This means that

the routing algorithms in Pastry are able to cope with

node failures or a dynamic participation of nodes.

Past (Rowstron and Druschel, 2001b) is an exten-

sion of Pastry for persistent storage of objects within

the overlay network as a DHT. While Pastry manages

the nodes of the overlay network, Past offers func-

tions to insert, lookup and retrieve objects on the peer

nodes. To achieve a high availability and robustness

against failures in a dynamic peer-to-peer network,

objects are replicated and the replicas are stored on

adjacent nodes. Since adjacent ids in the logical ad-

dress range usually do not represent peers that are ad-

jacent in the underlying physical network, this leads

to a wide distribution of replicas over physically re-

mote nodes. This reduces the risk of objects not be-

ing available when several neighboring nodes leave

the network.

Scribe (Rowstron et al., 2001) is a decentralized

multicast infrastructure based on Pastry. It provides

the functionality of a publisher/subscriber model for

messages and events. This extends Pastry with a very

ﬂexible and efﬁcient event distribution system. The

multicast-trees in Scribe reorganize themselves when

nodes leave or join the network. With the same repli-

cation mechanisms as in Past, this leads to the same

stability and ﬂexibility.

3 REQUIREMENTS FOR A

PEER-TO-PEER CSCW

ARCHITECTURE

We will describe a set of requirements that a peer-to-

peer based CSCW architecture must fulﬁll to provide

a usable basis for distributed collaborative systems.

FUTURE COLLABORATIVE SYSTEMS BETWEEN PEER-TO-PEER AND MASSIVE MULTIPLAYER ONLINE

GAMES

341

A distributed CSCW architecture is expected to offer

the same stability and much of the same functional-

ity that traditional client-server architectures provide.

However, they should also provide much of the same

basic functionality of established client-server CSCW

architectures, therefore we will present a basic set of

such requirements.

Since virtual knowledge spaces have proven to be

a solid and ﬂexible concept for collaborative systems

architectures (Bopp et al., 2006), we will also propose

them as a basis for a peer-to-peer based architecture.

A sophisticated user and permissions management is

a necessity for collaborative systems as is a mecha-

nism for dispatching and receiving events or notiﬁca-

tions within the system. We will describe these cen-

tral requirements in greater detail in the following sec-

tions.

3.1 Virtual Knowledge Spaces

Virtual knowledge spaces (“rooms”) are persistent

containers for documents, users and other objects, but

also act as nodes for synchronous as well as asyn-

chronous communication and collaboration. They

form the basis for continuous, location- and time-

spanning cooperation. Since rooms can be interlinked

with exits and can contain other rooms they can be

used to create structures or hierarchies, thus providing

a solid base for individual and collaborative structur-

ing of knowledge.

The representation of rooms can open up their

functionality in different ways, e.g. a chat program

could access a room as a communication channel,

a ﬁle browser could access the room like a virtual

folder in the ﬁlesystem, while at the same time a web

browser could list the users and documents contained

in the room. All these custom views work on the same

data, but can provide functionality and representation

tailored to their use. If virtual knowledge spaces are

implemented in a software that also provides standard

protocols like HTTP, WebDAV, FTP, IRC or XMPP,

then this would enable users to use their preferred

client software also for their collaborative work.

The functionality of custom views can also be tai-

lored to speciﬁc roles or tasks. A room could pro-

vide a view for students where they can submit assign-

ments and are able to view and change their own as-

signment up to a certain deadline. A different view for

tutors could then list all submitted assignments and

provide means to comment on them and rate them,

which in turn would be accessible only by the stu-

dents that submitted that assignment.

3.2 User and Permissions Management

Functionality like this obviously requires a sophis-

ticated permissions management. Users should be

assignable to groups that can be used to organize

them but also to simplify access rights by consider-

ing groups as roles (e.g. guest, student, tutor, ad-

ministrator, etc.). Groups should also be able to con-

tain sub-groups, so that ﬂexible or hierarchical user

management becomes possible. Access Control Lists

stored on objects and rooms can provide a good basis

for permissions management, although the common

“read”, “write” and “execute” permissions known

from ﬁlesystems are not differentiated enough for

CSCW systems. A ﬁner granularity of permissions is

needed, e.g. “change content”, “delete”, “move” and

“insert” instead of just “write”. One aspect that truly

unfolds the possibilities of virtual knowledge spaces

is the inheritance of permissions from other objects,

e.g. the environment that an object is contained in.

This makes taking a document and putting it into a

different room possible without having to change the

permissions afterwards to allow the users with access

rights to the target room to also access the document

that has been placed there. This allows a very in-

tuitive and at the same time very sophisticated and

ﬂexible permissions management on the basis of vir-

tual knowledge spaces. An additional permission ﬂag

that opens up new usage scenarios is the right to del-

egate permissions to other users. This “sanction” per-

mission provides a mechanism for self-administration

where users who have the “sanction” permission on

an object can delegate the other permissions they have

on the object to other users.

3.3 Event System

To support awareness mechanisms in synchronous

clients, the architecture must also support the cre-

ation, subscription and distribution of events between

different components and, in the case of a distributed

architecture, between different peers. More generally

speaking, events can form the basic means of interac-

tion between components of the software, providing a

ﬂexible infrastructure that additional components can

easily interface with.

4 PEER-TO-PEER

ARCHITECTURE FOR CSCW

Based on the overlay network described in section 2

and realized as a distributed multiplayer game archi-

tecture (see section 5) and the CSCW concepts of sec-

ICEIS 2007 - International Conference on Enterprise Information Systems

342

tion 3, we will now describe a peer-to-peer architec-

ture for CSCW systems.

4.1 Basic Network Layers

For an easier to maintain architecture, the proposed

CSCW system doesn’t implement the peer-to-peer

network functionality itself. Instead the application

is divided into abstraction layers, as shown in ﬁg-

ure 1: the peer-to-peer overlay network is layered on

top the physical network, a persistence layer provides

access to the network resources and event routing in

a more generic way and presents this functionality to

the CSCW system itself. This keeps the overlay net-

work code out of the main application and would even

allow exchanging the DHT implementation later on.

Overlay-Netzwerk

CSCW

overlay network

physical network

Overlay-Netzwerk

virtual knowledge

spaces

routing: Pastry

multicast: Scribe

persistence layer

persistence

management

collaborative system

event management

persistency: Past

Figure 1: Basic layers of a distributed CSCW architecture.

Our architecture uses Pastry, Past and Scribe for

the overlay network layer and implements a persis-

tence layer for persistent object storage and event

routing on top of it. Higher level functionality, like

access rights management, are then based upon this

object model and are located in the collaborative sys-

tems layer.

4.2 Distributed Virtual Knowledge

Spaces

Virtual knowledge spaces inherently subdivide the

persistence space into smaller segments, rooms. Fig-

ure 2 shows how virtual knowledge spaces are real-

ized as sub-networks within the Pastry network. We

map these rooms to Scribe multicast groups to achieve

a smaller overlay network within the whole Pastry

network. Communication within a knowledge space

is therefore done by multicasts inside the group. This

allows us to route events based on objects within a

room only to those nodes that are registered to receive

events for those objects, concentrating the main band-

width demand of intense, synchronized user interac-

tion to the network connections between those peers

that take part in that interaction. This means that users

collaborating within a shared whiteboard and using

voice or video chat will not ﬂood the network con-

nections between other peers within the same collab-

orative system.

Figure 2: Virtual knowledge spaces in a Pastry overlay net-

work.

Figure 3 shows how an action like “give a copy

of a document to another user” is performed in a dis-

tributed collaborative system. A copy of the docu-

ment is created and referenced by the target user’s in-

ventory. The document is not necessarily placed on

the same peer node as the user or the original docu-

ment, but it can be referenced through the routing of

object ids in Pastry. Since the document inherits the

access rights of its environment by default, the target

user can then access it or place it in another room, e.g.

her personal workspace or a group workspace.

To synchronize the communication within a

group, we introduce controller peers that act as a

server-like entity. The state of all objects inside the

knowledge space is managed by this controller peer.

If a peer wants to change the state of an object, it re-

quests this change by sending a message to the con-

troller peer, which processes this request. The con-

troller peer then multicasts the changes to the other

members of the group. For higher security and stabil-

ity we introduce backup controllers, that monitor the

actions of the controller and can take over in case of

failure or misbehavior of the controller peer.

The region controller and the backup controllers

need (and should) not be peers that are involved in

FUTURE COLLABORATIVE SYSTEMS BETWEEN PEER-TO-PEER AND MASSIVE MULTIPLAYER ONLINE

GAMES

343

Figure 3: Actions across knowledge spaces: region-

spanning event distribution.

that room themselves. This reduces the chance of

manipulated peers to deliberately access or modify

data. Since the region controller is supervised by the

backup controllers, all these peers would need to be

compromised in order to be able to “cheat” objects

they control. These controller peers can be regarded

as a ﬁrst interface where enhanced security mecha-

nisms can be integrated in the future.

4.3 Connecting to the Overlay Network

To join a peer-to-peer network some kind of boot-

strapping is needed. This means the user needs an

address to connect to, from which all necessary net-

work information is delivered to the new node, so that

it can be integrated into the network. Depending on

the usage scenario different methods are available. In

a local environment an architecture like Bonjour / Ze-

roconf can be used to discover nodes that offer a boot-

strap service for the overlay network. In closed sys-

tems, where new users have to be invited to join the

network, the bootstrapping info can be attached to the

invitation message.

In a pure peer-to-peer setting, a user account is

created by producing a public/private encryption key

pair, storing the public key in the overlay network un-

der the name or login name of the new user. To au-

thenticate, a user would later send a message signed

with her private key into the overlay network. This

message can be veriﬁed with the public key to authen-

ticate the user.

In all other scenarios some rendezvous server has

to be established. This server would have a static net-

work address, that is known by new nodes and could

also offer authentication or accounting services if re-

quired, accessing central LDAP or Kerberos servers

for example. Such central servers could also offer

services that are traditionally provided under static

addresses, like HTTP for the publishing of websites,

FTP or WebDAV for ﬁle transfer, IRC or XMPP for

chat, etc. It would also be possible to run such a

central peer node inside a webservice container like

Apache Tomcat, so that it can provide functionality

of the distributed collaborative system to traditional

webservice clients through the SOAP protocol.

The main drawback of using central “superpeer”

nodes is that they will suffer high bandwidth require-

ments and be single points of failure. On the other

hand, a number of superpeers can also be used as

replication nodes for important data, thus guarantee-

ing the availability of certain data even in the unlikely

case that all other peers with replicas of that data are

disconnected from the network.

4.4 Searching

While looking up objects by their id is handled by

Pastry, searching for resources in peer-to-peer net-

works is a non-trivial task that is mostly done by ei-

ther introducing superpeer nodes that index resources

or by plain broadcasting of search queries into the

overlay network. Both approaches have shortcomings

though. With superpeer nodes you have single points

of failure. If such a node fails, large parts of the net-

work become unsearchable. On the other hand broad-

casting wastes bandwidth and processing power on all

nodes (Charwathe et al., 2003).

We propose a different solution for this problem,

by creating Scribe groups for each search word. If

a node has a resource, that should be available by

searching, it joins the Scribe group for all relevant

search words. If another node wants to access all re-

sources related to a given topic, it publishes a mes-

sage to the Scribe group of that topic. The query is

then multicasted to all members of that group. Since

all group members have documents that are relevant

to that topic, they send a message back to the origi-

nal sender with the requested information. This sim-

ple algorithm obviously works only for single search

words, but can be easily extended to support complex

querys including AND and OR constructs.

To improve search results further we use tagging

functions similar to popular web applications like

Flickr

, which allow users to tag resources. These

tags can then be searched by the system.

Flickr is an online photo community where users up-

load photos and tag them with keywords: http://ﬂickr.com

ICEIS 2007 - International Conference on Enterprise Information Systems

344

5 DEMONSTRATOR – A

PEER-TO-PEER MASSIVE

MULTIPLAYER ONLINE GAME

To demonstrate our approach we implemented a mas-

sive multiplayer online game (MMOG) version of the

classic snake game (ﬁgure 4). The game world is

divided in regions and each region is assigned to a

controller peer. The snake controlled by a player is

always in one of these regions. The player can en-

ter neighboring regions by crossing the screen bor-

der. If he/she does so, his/her snake is assigned to

the new region and is deleted from the old region.

Currently it is not possible for a snake to gradually

change to a region piece by piece. To speed up the

region change, the player node not only subscribes

to the Scribe group of the current region it is in, but

also to all neighboring regions. Upon region change,

the new region is already joined and the new neigh-

bors can be joined in the background, while the game

is continuing. This behavior is not needed in CSCW

systems, since there is usually no need for fast region

changes. We currently send the game state of each

region every 100 milliseconds, which is an update

rate not needed for most CSCW applications. Syn-

chronous clients like shared whiteboards might bene-

ﬁt from high update rates to provide smooth, real-time

cooperation. The architecture is described in detail in

(Hampel et al., 2006).

We’ve successfully run 128 instances (8 comput-

ers, each running 16 instances) of the snake game to

measure stability and bandwidth usage (ﬁgure 5). The

ﬁgure shows the average bandwidth used by a peer in

the network in kbytes per second with a ﬁxed number

of 9 regions. We have found that the average band-

width usage does not depend on the number of peers,

but rather on the number of active regions. This is

shown in ﬁgure 6, where we measured increasing re-

gion numbers with a ﬁxed peer number of 8. The av-

erage bandwidth usage is quite high in our test set-

tings because of our high update rate and the fact that

each player not only joins the region his snake is in,

but also all neighboring regions. This would not be

the case in a CSCW-system since a peer only has to

join the region the user is currently in.

6 RELATED WORK

SimMud (Knutsson et al., 2004) is a proof-of-concept

massive multiplayer online game architecture. It is

also based on Pastry as a distributed hash table over-

lay network and the Past and Scribe extensions. Sim-

Figure 4: Screenshot of MMOG-Snake with 16 instances.

2 4 6 8 10 12 14 16

KByte/s

Number of Nodes

Figure 5: Average bandwidth usage with 9 regions and in-

creasing peers.

Mud has shown that such a system scales well with

large numbers of users even in synchronous settings.

OceanStore (Kubiatowicz et al., 2000) is a con-

cept for a distributed ﬁlesystem, which focuses on the

availability of data. This is accomplished by distribut-

ing the data on the nodes of an overlay network based

on Pastry. All data is secured with cryptographic al-

gorithms and stored redundantly to guarantee high

availability.

OpenDHT (Rhea et al., 2005) is a service imple-

mentation of a distributed hash table. It provides a

simple interface to retrieve and store data. This could

qualify it as a persistence layer for CSCW systems.

Groove

is a hybrid architecture, where a central

server provides an entry point into the distributed net-

work of peers and also stores changes for peers who

are ofﬂine. The main focus of Groove is support for

decentralized, synchronous collaboration.

www.groove.net

FUTURE COLLABORATIVE SYSTEMS BETWEEN PEER-TO-PEER AND MASSIVE MULTIPLAYER ONLINE

GAMES

345

9 12 15 18

KByte/s

Number of regions

Figure 6: Average bandwidth usage with 8 peers and in-

creasing regions.

7 CONCLUSION AND OUTLOOK

A peer-to-peer architecture for CSCW systems is fea-

sible. Our demonstrator application shows that net-

work bandwidth only increases logarithmically with

the number of connected peers. This simulation was

a synchronous, highly interactive setting which can be

regarded as a ”‘worst case”’ scenario for synchronous

collaborative work, e.g. with a shared whiteboard.

Most actual uses will have much less frequent event

messages, resulting in even less bandwidth require-

ments. A peer-to-peer-based architecture is therefore

highly scalable even for synchronous collaboration

between large numbers of users. Since storage space

and processing power are supplied by all peers, these

resources even grow with increasing numbers of con-

nected peers, while replication strategies ensure avail-

ability of data even in case many peers disconnect.

Our architecture is based upon virtual knowledge

spaces on a peer-to-peer persistence layer. This per-

mits distributed collaborative systems complying with

the basic requirements for collaborative architectures,

such as persistent object storage and an event distri-

bution mechanism.

There are, however, aspects that still need to be

investigated in greater detail. Security is one of the

main concerns. A peer-to-peer CSCW framework

must guarantee that data is only accessible by those

that are entitled to it through the system’s permission

management. Since the functionality of the system is

not conﬁned within a single server, there must be re-

liable mechanisms that prevent a compromised peer

to bypass access management of the software. A ﬁrst

approach is the use of region and backup controllers,

but more sophisticated security measures should be

researched.

REFERENCES

Bopp, T., Hinn, R., and Hampel, T. (2006). A service-

oriented infrastructure for collaborative learning in

virtual knowledge spaces. In Kumar, D. and Turner,

J., editors, Education for the 21st Century – Impact of

ICT and Digital Resources, volume 210, pages 35–44.

International Federation for Information Processing,

Boston: Springer.

Charwathe, Y., Ratnasamy, S., Breslau, L., Lanham, N., and

Shenker, S. (2003). Making gnutella-like p2p systems

scalable. In Proceedings of the ACM Conference on

Applications, Technologies, Archite ctures, and Pro-

tocols for Computer Communications (SIGCOMM),

pages 407–418. ACM Press.

Hampel, T., Bopp, T., and Hinn, R. (2006). A peer-to-peer

architecture for massive multiplayer online games. In

Proceedings of 5th ACM SIGCOMM workshop on

Network and system support for games NetGames ’06.

Knutsson, B., Lu, H., Xu, W., and Hopkins, B. (2004). Peer-

to-peer support for massively multiplayer games. In

Proceedings of the Conference on Computer Commu-

nications (INFOCOM).

Kubiatowicz, J., Bindel, D., Chen, Y., Eaton, P., Geels, D.,

Gummadi, R., Rhea, S., Weatherspoon, H., Weimer,

W., Wells, C., and Zhao, B. (2000). Oceanstore: An

architecture for global-scale persistent storage. In Pro-

ceedings of the 9th International Conference on Ar-

chitectural Support for Programming Languages and

Operating Systems (ASPLOS), pages 190–201. ACM.

Mizrak, A., Cheng, Y., Kumar, V., and Savage, S. (2003).

Structured superpeers: Leveraging heterogeneity to

provide constant-time lookup. In Proceedings of

the 3rd IEEE Workshop on Internet Applications

(WIAPP), pages 104–111, San Jose, CA, USA.

Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Rat-

nasamy, S., Shenker, S., Stoica, I., and Yu, H. (2005).

Opendht: a public dht service and its uses. In Pro-

ceedings of the ACM Conference on Applications,

Technologies, Architectures, and Protocols for Com-

puter Communications (SIGCOMM), pages 73–84,

New York, NY, USA. ACM Press.

Rowstron, A. and Druschel, P. (2001a). Pastry: Scalable,

decentralized object location, and routing for large-

scale peer-to-peer systems. Lecture Notes in Com-

puter Science, 2218:329–350.

Rowstron, A., Kermarrec, A.-M., Castro, M., and Druschel,

P. (2001). Scribe: The design of a large-scale event

notiﬁcation infrastructure. In Proceedings of the Con-

ference on Networked Group Communication, pages

30–43.

Rowstron, A. I. T. and Druschel, P. (2001b). Storage man-

agement and caching in past, a large-scale, persistent

peer-to-peer storage utility. In Proceedings of the Sym-

posium on Operating Systems Principles, pages 188–

201.

ICEIS 2007 - International Conference on Enterprise Information Systems

346