P2P Journal. July.

2003
Page 1
JuIy, 2003 Issue
P2P Journal. July. 2003
Page 2
Contents for JuIy, 2003
To P2P or P2P Too: A discussion of Peer-to-Peer and
Related Technologies
by Raymond Gao
This articles talks about Peer-to-Peer (P2P) technology and platIorms in general. It
discusses the diIIerence between P2P and client-server models.
The Socket API in 3XTA 2.0
by Daniel Brookshier
This article talks about JXTA socket APIs and provides code example on how to
use those APIs.
How Peer-to-Peer Computing Helps Momentum Users
Organize and Manage Information
by InView SoItware
This whitepaper talks about Inview SoItware's Momentum soItware. a
collaborative computing application with build-in document sharing. versioning.
and repository. instant messaging. and white board capabilities.
Call for Paper
Use P2PJ's message board Ior all discussion related to this issue.
Cover Image: Kiss in the Moon. an oil-painting by Raymond Gao. 2000.
This picture depicts the complex duality in human nature.
(Size 14" x 19")
Editor-in-ChieI: Raymond Gao. raygao(attbi.com
JXTA Track Editor: Daniel Brookshier. turbogeek(cluck.com
Various other track editor positions are open Ior application. contact editor(p2piournal.com Ior detail.
Copyright 2003: Unless with explicit written permission Irom P2P Journal. no part oI this iournal
may be recycled or reproduced in whole or parts.
3
10
17
23
P2P Journal. July. 2003
Page 3
To P2P or P2P Too: A discussion of Peer-to-Peer and Related
Technologies*
By Raymond Gao
Peer-to-Peer (P2P) technology has been receiving
much publicity over the last three years. though
the idea behind P2P went Iar back. I remember
getting introduced to 'talk¨ command on Unix and
chatting with Iriends over VAX terminals. And.
when I was in college. I had used a Macintosh
program called JCRemote to share documents and
Iiles over the AppleTalk network.
In Iact. the present day web-based computing
model and P2P technology share many similarities.
Both are progenies Irom the same parents oI the
distributed computing and networking technology.
In a broader sense. the domain name system
(DNS) model. which is employed to resolve
domain names and IP addresses on the web.
behaves similar to a Iixed rendezvous peer in the
P2P Iramework.
What is P2P technology?
Speaking broadly. P2P computing deIines
reciprocal and instantaneous interaction between
two or more networked endpoints. Those
endpoints could be devices ranging Irom a PC. to a
Unix workstation. a Iile server. a mainIrame. a
handheld device. i.e. personal digital assistant
(PDA). a cell phone. a wristwatch. or even a MP3
player. II those endpoints exist on equal and
parallel organizational levels. they are considered
as peers in a P2P conversation. The deIintion oI
general distributed computing reIers to that those
endpoints should be hosted on individual
environments. separate operating systems (OS)
and process threads.
Recently. P2P technology has undergone many
new developments and innovations. which were
motivated by desires in creating a natural
computing environment that can selI-regulate
between resource supply and consumption. P2P
opens up a new computation model where
scalability and availability is not constraint by a
single / centralized server(s). as experienced in the
traditional client-server design. P2P Iacilitates many-
to-many relationships.
A comparison of P2P model and client-
server model
To a theoretician. the primary diIIerence between
the web-server / browser model and the P2P
technology is that the Iormer uses Iixed and static
top-level DNS servers with pre-determined domain
tree structures. i.e. .com. .edu. .org. .tv. etc. while.
the latter uses dynamic protocols to resolve service
providers. However. in actual implementation. there
are many other diIIerences.
Eirst. one must understand why people use Internet
and what kinds oI applications are used. Nowadays.
leading transport protocols used on internet include
hyper-text transport protocol (HTTP). Iile transport
protocol (ETP). e-mail protocols simple mail
transport protocol (SMTP). internet mail access
protocol (IMAP). post oIIice protocol version 3
(POP3). instant messaging (IM) & internet relay
chat (IRC) protocols. network news transport
protocol (NNTP). and various multi-player game
protocols. etc. People use Internet Ior inIormation
retrieval. Ior communication and discussion.
gaming. and other entertainment.
Distributed service can be provided in many
diIIerent ways. A traditional choice is based on the
client-server model. as shown in Eigure 1.
In contrast. a P2P powered network adheres to the
concept that endpoints are to be organized in a
parallel Iashion. as shown in Eigure 2.
The two diagrams stress a key diIIerence client-
server wants to centralize; and. P2P wants to push
inIormation to the edge. Under most server-centric
model. clients are peripheral associates and must
rely on the server to gain indirect communication
with each other. On the other hand. P2P model
allows every endpoint to Iunction as both a client
* This paper is part one oI a series oI paper discussing in detail P2P platIorms
and relevant issues. such as security. scaling. and integration with other
distributed computing and messaging technologies.
P2P Journal. July. 2003
Page 4
and a server and to have direct access to its
counterparts.
Eigure 1. Server-Centric Model
Eigure 2. P2P Model
Table 1 shows a comparison oI two models.
Different P2P models and their
implementations
SoItware designer each has his/her ideas and
makes diIIerent assumptions. DiIIerent design
considerations result in diIIerent architecture or
soItware models. There are numerous P2P
platIorms and protocols. Currently. leading P2P
platIorms includes Proiect JXTA. Jabber. Gnutella.
Ereenet. Groove Networks. MicrosoIt Windows XP
P2P SDK. and many more.
Proiect JXTA
Proiect JXTA is a set oI open protocols that allow
any connected device on the network ranging Irom
cell phones and wireless PDAs to PCs and servers to
communicate and collaborate in a Peer-to-Peer (P2P)
manner. It is a programming platIorm Ior P2P
computing much like Java technology is Ior Web
development. Proiect JXTA deIines a common set oI
protocol deIinitions and API lists which allow
developers and companies to built interoperable
application or service without replicating redundant
eIIort or relying on proprietary technologies.
Proiect JXTA's architecture model is divided into 3
layers. The bottom core layer deals with low-level
plumbing activities. such as peer establishment. pipe
communication. peer and peer group monitoring.
routing. etc. It is the Ioundation upon which
everything else is built. Some important Iunctions
include providing and administration security. using
and resolving P2P protocol calls. such as PIP (Peer
InIormation Protocol). Peer Discovery Protocol
(PDP). Peer Resolver Protocol (PRP). Rendezvous
Protocol (RVP). servicing group membership
monitoring issues. Iailing over to next peer during
network error. etc.
The middle service layer addresses higher-order
concerns. such as indexing. searching. and Iile
sharing. These services are built on the top oI
Proiect JXTA's core layer. They are commonly
integral parts oI a P2P system or application.
The top layer is the application layer. Sample P2P
applications include instant messaging.
collaboration. resource sharing (using compute
cycles on underutilized machines) and content
sharing. Proiect JXTA is a thin and lightweight layer
on top oI which services and applications are built.
Introduced by Sun Microsystems. Proiect JXTA is
developed under the open source model. meaning
the source code Ior the platIorm technology is Ireely
available to everyone. There are over 13.000
members oI Proiect JXTA's community. many oI
them are using and continually improving the
technology.
Proiect JXTA is short Ior Juxtapose. as in side by
P2P Journal. July. 2003
Page 5
Server-based model P2P model
Information Ownership Server-based. a single server or a
pre-determine set oI servers
Peer-based. dynamically adiusted.
based on content availability
Content is organized By domain By peer group or topic
Content is backed-up On Secondary or mirror site Potentially. every peer can act as a
mirror
Primary Endpoint behavior As a client As a client. a server. or a super-peer
(rendezvous or router peer)
Information Retrieved Erom the server Eor closest edge peer
Address resolution & discovery
mechanism for finding a host
Via name servers based on DNS
entry; DHCP is possible with
network address translation (NAT)
service
Via the query response Irom the
rendezvous peer or using peer
discovery protocols
New content originates from The central server and gets pushed
to the edge
Any edge peer and propogates
through out the network
Traffic Routing Via router Via router peer
Primary point of contact A central server A peer group. a topic. or a single
peer
Communication among clients Centrally coordinated by a central
server
SelI-regulated by peers themselves
Scalability Limited by the server Limited by the network
Where to add new content On the server On any peer
Effect of adding new clients Increase resource demand / load on
the server
Increase the number oI available
data sources
Fail-over / Interruption & Resume
Service
Eail-over to backup site. when all
backup sites are exhausted. the site
is down
Eail over to secondary peer
Message propagation Pattern Radiate Irom the server. broadcasted
Irom a central source
Propagates based on ad hoc
connections between the peers.
queries & responses.
Denial of service (DOS) attack Bring the main site down Brings a single peer or peer group
down
Bottleneck The server or the network The network
Cost-effective security
implementation
On the server On each peer. peer group. or super-
peer
Content management & message
filtering
On the server. centralized Each peer makes its own decision
based on query responses and
comparative scores oI multiple
results
Table 1. A comparison oI P2P and Server-based Model
P2P Journal. July. 2003
Page 6
side. It is recognition that peer-to-peer is iuxtapose
to client server or Web based computing.
Gnutella
Gnutella is another popular P2P protocol. initially
developed by programmers at Null SoIt. It
primarily orients itselI toward the Iile and music
sharing community.
Gnutella could be labeled as one oI the Iirst true
P2P applications or protocols. All computers
running Gnutella protocol enabled program are
said to be on the Gnutella Network (gNet). That
allows computers on the World Wide Web to
connect in parallel to each other. On the gNet. a
user can connected simultaneous to several other
computers and either retrieve or provide
inIormation to them. There are multiple hosts
operating at a single time. And. those hosts oIten
rotate depended on whether those machines are
powered on or oII.
Gnutella diIIers Irom Napster in that there is no
one Iixed central server Ior Gnutella. Under its
initial architecture model. Gnutella clients used a
dynamic discovery method to Iind peers and other
Gnutella hosts on the Internet. That architecture
had problems due to insuIIicient consideration Ior
network issues and scalability. PerIormance and
response time suIIered as more people ioined
gNet. Soon. there were excessive network traIIic
generated by pinging and protocol routing. Thus.
some newer implementations made adiustments to
the discovery mechanism to account Ior network
delay. packet size. hop counts. etc. As a Iile-
sharing program. Ireeloaders are always an issue.
Gnutella client and server are customarily
packaged into one single binary distribution. That
meant other applications. such as web browsers
and mail/news applications. could also participate
or rely on those services. There are many diIIerent
clients available Ior Windows. Unix. Macintosh.
and Linux platIorms.
Gnutella version 0.56 is the basic and hence most
agreed upon standard. There has been discussion
about Gnutella version 2. But. there is yet to see
concrete implementation or deIinitive agreement
Ior Gnutella v2.
Instant Messaging (IM)
People oIten build P2P application with IM
capability. IM allows people to interact in real-time
by rapidly exchanging short messages. Iiles and
inIormation. Some IM systems may even Iacilitate
voice and/or video transIer. IM appears to be a
leading alternative to real-time email system. It is
used in a less Iormal manner than composing e-
mails. IM users will directly and immediately
response. There are many diIIerent IM clients
available. (See http://p2piournal.com/main/im.htm
Ior that list.)
Because its popularity. companies. such as Jabber.
have gone ahead and developed common IM
platIorms and toolkits.
Jabber
Jabber targets the instant messaging (IM)
community. It is a hybrid between the P2P and the
client-server architecture. It can be best described as
an 'instant e-mail¨ protocol. Jabber delivers
messages without delay; vs.. an e-mail application
will queue up multiple messages and send them out
in a batch.
Jabber is open-source based. meaning that the source
code is Ireely available to developers.
Jabber's message is stream based and uses XML
Iormat. meaning that its message scheme is
extensible. By deIault. Jabber protocol runs on port
5222. Each Jabber user is assigned a Jabber ID (JID)
and an initial home server. A JID is Iormed in the
Iormat consisting domain name. node. and resource.
as shown below:
|node(|domain|/resource|
The node identiIies the user. And. a user is allowed
to have access to multiple resources or devices. Ior
example kemehameha(oahu/canoe or
kemehameha(oahu/palace. Jabber stresses an
important concept called 'presence¨. 'Presence¨
identiIies whether a user is online or oIIline. A
resource is only valid within a speciIic session. Once
a session expires or a user signs-oII/disconnects.
his/her resources are invalidated.
Jabber proiect was started in early 1998 by Jeremie
Miller. In May 2000. iabberd 1.0 was released. Now.
the Jabber protocol is under the auspices oI the
P2P Journal. July. 2003
Page 7
Jabber SoItware Eoundation. Many Jabber-based
soItware proiects are hosted on
http://www.iabberstudio.org website. Eor example.
there are at least Iour Jabber server
implementations. libraries Ior a wide variety oI
languages. and clients Ior everything Irom Amiga
to Windows.
Internet Relay Chat (IRC)
Jarkko Oikarinen wrote the Iirst widely used IRC
client in 1988. Now. IRC has appeared in over 60
countries around the world. IRC is a multi-user
chat system. where people meet in "channels" or
rooms. virtual places. or to talk in private. There is
no restriction on the number oI people that can
participate in a given discussion. or the number oI
channels that can be Iormed on IRC.
There are many IRC clients. A leading IRC
application is called mIRC. available at
http://www.mirc.com. Eor a comprehensive list oI
IM clients. visit
http://p2piournal.com/main/im.htm.
Ereenet
Ereenet is a proiect began by Ian Clark. The goal
oI Ereenet is to promote inIormation sharing on the
Internet without Iear oI censorship. To achieve this
Ireedom. the network is entirely decentralized and
publishers and consumers oI inIormation are
anonymous.
Communications between Ereenet nodes are
encrypted and are "routed-through" other nodes to
make it extremely diIIicult to determine who is
requesting the inIormation and what is its content.
Users contribute to the network by giving
bandwidth and a portion oI their hard drive (called
the "data store") Ior storing Iiles. Unlike other P2P
Iile sharing networks. Ereenet does not let the user
control what is stored in the data store. Instead.
Iiles are kept or deleted depending on how popular
they are. with the least popular Iiles being
discarded to make way Ior newer or more popular
content. Occasionally. the insertion oI a new Iile
with the same name would cause old Iiles to be
propagated in the network.
Ereenet runs as a Daemon process. Ered (the
Ereenet ReIerence Daemon). in the background. A
typical user initiates conversation with the hosting
Ered as a client process. Additionally. Ered oIIers a
service called Iproxy. which lets you talk to Ereenet
with a web browser. Pointing your web browser to
port 8888 will load up the gateway page.
Currently. Ereenet does not have a search
mechanism. That is in part due to the initial design
assumption that places a greater importance on
anonymity over perIormance and inIormation
archiving. InIormation is retrieved by using "keys".
Typically. an author will post his/her documents or
Iiles on a node and then advertise it through
broadcasting e-mail messages. advertising it through
the submission Iorm on Ereenet 'portal¨ sites.
registering it with web search engines. or
announcing it via IRC channels. such as
irc.Ireenode.net #Ireenet. While adding a Iile. a key
is generated. That Key is in the Iorm oI a location-
independent Globally Unique IdentiIier (GUID).
Ereenet employs two main types oI keys: 'content-
hash keys¨. used Ior primary data storage. and
'signed-subspace keys¨. intended Ior higher-level
human use. The two are analogous to inodes and
Iilenames in a conventional Iile system.
The core Ereenet package is distributed in open-
source Iormat. It is written in Java. The required
Java runtime environment is JDK 1.1. The most
current release is Ereenet 0.5.2-rc2. available since
15th May 2003.
Groove Networks
Ray Ozzie who had started Lotus Notes Iounded
Groove Networks in October 1997. Groove suites oI
products are built around the Groove Workspace
product. Groove Workspace works similar to a
virtual web server. allowing associates to view and
edit documents that reside remotely on workspace
owner's computer. Duplicate copies oI original
documents can be placed on share space members'
computers. That allows a workspace owner to access
his/her Iiles using other member's computer in event
oI computer problems or his/her PC out oI reach.
Groove Workspace integrates with MicrosoIt OIIice
(Word. Outlook. Proiect). Documentum. and
SharePoint Server. It runs on Windows
98/NT/2000/ME/XP platIorms.
Groove oIIers a soItware developer's kit called
Groove Developer Kit (GDK). which is based on
MicrosoIt's component obiect model (COM) and
requires MicrosoIt Visual Studio. It works with C¹¹.
P2P Journal. July. 2003
Page 8
Visual Basic (VB). and various scripting
languages. such as JavaScript. VBScript. and Perl.
In order to use .NET's managed service API or C#.
you must use Groove Toolkit (GTK) to bridge the
gap between COM and .NET Irameworks.
Additionally. Groove has a web services toolkit
called Groove Web Services Development Kit
(GWS GDK).
Groove Networks uses 192-bit encryption to
secure communication between users. Groove also
claims its products are Iault-tolerant and work
across Iirewall.
To support enterprise capabilities. Groove has also
built additional products. Groove Relay Server to
pass messages across Iirewall. Groove
Management Server to provide a single centralized
management console. and Groove Integration
Server to provide connection to other knowledge
systems. such as CRM. ERP. and third party
messaging servers.
Groove Workspace's most current release is 2.5.
GDk's most current release is 2.0.
MicrosoIt XP Peer-to-Peer SDK
The Windows XP Peer-to-Peer SDK provides
application developers with an inIrastructure and a
set oI APIs to create peer-to-peer applications.
APIs are provided Ior Windows P2P networking
name resolution. graphing. networking grouping.
and identity manager. Detailed explanation is as
Iollows:
1. Windows P2P Networking Name Resolution:
The Peer Name Resolution Protocol (PNRP)
Name Space Provider provides an API that
enables peer-to-peer resolution oI names to
endpoints (IPv6 address/port number).
2. Windows P2P Networking Graphing:
Graphing enables eIIicient multipoint
communication among a tightly coupled set oI
peers. Graphing enables applications to
leverage/plug in their own security models and
name resolution mechanisms.
3. Windows P2P Networking Grouping:
Grouping is the security layer provided by
deIault on top oI a graph. The security layer
deIines the security model behind group
creation. invitation. and connection to the group.
In addition. Grouping leverages PNRP as the
name resolution protocol - and enables multiple
applications to share the same graph.
4. Windows P2P Networking Identity Manager:
Identity manager enables creation oI peer-to-peer
identities to be used in PNRP and Grouping.
The Windows XP P2P SDK contains
documentation. header and library Iiles. and two
sample applications.
SYSTEM REQUIREMENTS
Windows XP with Service Pack 1
PC with 300 megahertz (MHz) or higher processor clock
speed recommended; 233-MHz minimum required; Intel
Pentium/Celeron Iamily. AMD K6/Athlon/Duron Iamily. or
compatible processor recommended
128 megabytes (MB) oI RAM or higher recommended
(64 MB minimum supported)
20 MB oI hard disk space
Windows XP P2P SDK is currently available as a
beta release and Iuture updates are hosted on
MicrosoIt's BetaPlace Web site
(http://www.betaplace.com).
What's next?
We have examined some leading P2P platIorms in
this article. Some implementation models use a Ilat
organization structure and dynamic discovery
protocols to Iind peers and hosts. Other models are
hybrids oI a combination oI client-server
architecture and distributed query service to resolve
service providers on ad hoc basis. Each designer has
diIIerent philosophy that is reIlected in the
architecture. Eor example. which issues are most
important Ior their platIorm to address whether it is
security or anonymity. perIormance or Iault-
tolerance. scalability or ease oI use. compatibility
with other platIorms or clarity in architecture layout.
P2P technologies should be considered more as the
next step in the evolutionary process oI distributed
computing than a radical departure Irom other
networking technologies. In order that P2P
technology be truly useIul. whether it is in the
enterprise. commercial. gaming. educational.
research and development (R&D). government. or
end-user setting. many issues are waiting to be
elucidated. In the upcoming paper. we will discuss
P2P Journal. July. 2003
Page 9
issues concerning P2P security. collaboration.
perIormance. and scaling. In the part three oI the
series. we will look at P2P's 'cousins¨. other
distributed computing technologies. such as grid
and cluster. as well as how to integrate P2P
technology in the enterprise Iramework. and P2P
application's commercial values.
ReIerence:
1. http://Ireenet.sourceIorge.net/papers/Ireenet-
ieee.pdI - Protecting Ereedom oI InIormation
Online with Ereenet. An IEEE Internet Computing
article describing the Ereenet architecture circa
2002 (PDE Iormat)
2. http://Ireenet.sourceIorge.net/ - Ereenet proiect
hosted on SourceIorge.net
3. MicrosoIt Windows XP Peer-to-Peer SoItware
Development Kit(SDK) Website
4. http://ixta.org - Proiect JXTA's oIIicial website.
5. http://groove.net - Groove Networks' website
6. http://iabber.org - Jabber SoItware Eoundation's
website
7. http://www.irc.org - An IRC inIormation
website
8. http://www.rixsoIt.com/Knowbuddy/gnutellaIaq
.html - RixSoIt's Knowbuddy's Gnutella EAQ
9. http://open-content.net/ - Open Content
Network's website
10. P2P Journal - P2P Journal's website
Raymond Gao is the editor-in-chieI
oI P2P Journal. He has a proven track
record involving enterprise-level and
distributed computing proiects. He has
spoken widely and is well published.
He Iounded P2P iournal in early 2003.
His other interests include music. oil
painting. travel. and writing. He can be
reached at raygao(attbi.com or (972)
530-4562.
P2P Journal. July. 2003
Page 10
The Socket API in JXTA 2.0 *
By Daniel Brookshier
Peer-to-peer (P2P) computing is diIIicult enough
without having to learn a new application program
interIace (API). Proiect JXTA 1.0 introduced us to
P2P computing. But. its API was tough to learn
and did not easily mapped to our current process.
Now. with the release oI JXTA 2.0. you get your
warm Iuzzy Ieelings back. JXTA 2.0 APIs are in a
ready-made Iorm that can easily wrap around your
P2P communications with a socket-like interIace
and Java I/O streams.
This article is a tutorial on how to use the new
JXTA Socket API in JXTA 2.0. I'll also
demonstrate a simple method Ior locating a person
to chat with using a hash ID. With these two items
and a little glue. you can create many diIIerent
types oI useIul P2P applications.
In a Nutshell: Understanding P2P and
3XTA
Are you new to P2P and JXTA? Simply put. P2P
is iust the interaction oI two or more computers.
However. the story is much more complex than a
Iew cables. Eirewalls. Dynamic Host
ConIiguration Protocol (DHCP). and Network
Address Translation (NAT) devices hide the
identity and addresses oI computers and block
direct communications. And since there are
millions oI computers and devices connected to the
Internet. locating a speciIic device with a speciIic
resource is not obvious and doubly complex
because most devices are un-addressable and
Iirewalled. JXTA and other P2P protocols are
designed to solve these problems.
JXTA is a P2P protocol speciIication that includes
addressing. routing. messaging. and other services.
JXTA creates a virtual network that overlays the
mess oI un-addressable and blocked computers
with a uniIorm address space and network-level
Iunctions Ior discovering. grouping. and
communication between PCs and devices. JXTA is
a P2P protocol. It is available in several languages
and platIorms. including the Java language and C¹¹.
Why P2P now? Hasn't P2P existed since two
computers were Iirst networked? Today's massive
numbers oI connected devices with idle resources
are key reasons Ior P2P's current rise. P2P
computing can reduce your need Ior a large support
inIrastructure by substituting PCs in homes and
businesses as resources. rather than centralized
servers. Turning client-server programming upside
down is not always straightIorward. but the good
news are that the techniques and API are getting
simpler -- as you will see in the remainder oI this
article.
The Chat Application
The example I'll be using is very simple; Chat is
the equivalent oI Hel l o Wor l d Ior P2P. Here's all
we're going to do:
· Initialize the JXTA platIorm
· Create a server socket to wait Ior connections
· Process incoming connections. or initiate a
connection to another computer
· Once a connection is established. send messages
back and Iorth
Isn't it simple? In a way. it is. but JXTA (as
demonstrated in this example) will let you
accomplish a very complex task: Computers can
"chat" all over the world. without the need Ior a
server.
The 3XTA Socket API
Now that you understand a little about our
application. take a look at the classes in the JXTA
socket package:
· Jxt aSer ver Socket : Server socket that waits
Ior connections Irom clients.
· Jxt aSocket : Socket class used to create the
I/O streams Ior both clients and servers.
· Jxt aSocket l nput St r eam: Extension oI the
l nput St r eamabstract class.
* This article reprinted with permission by http://iava.sun.com. Minor editorial
changes have been made to make it consistent with other articles in the iournal.
P2P Journal. July. 2003
Page 11
· Jxt aSocket Out put St r eam: Extension oI
the Out put St r eamabstract class.
These classes have Iamiliar resemblance to what is
in the Java I/O package and have similar sequence
oI events to socket s classes in the j ava. i o
package too. We start with the creation oI a
Jxt aSer ver Socket on the computer waiting
Ior others to connect to it. A client (the caller)
computer uses the Jxt aSocket class to connect.
Both computers create the corresponding I/O
streams using Jxt aSocket . and begin talking
with each other. There is a bit more to do Iirst.
however. Remember that JXTA does not use IP
addresses. So it's time to initialize the JXTA
network and create a JXTA address.
Deeper into 3XTA Sockets
The classes Jxt aSer ver Socket and
Jxt aSocket are similar to the Socket and
Socket Ser ver classes in the Java I/O package.
The Jxt aSer ver Socket class is used to wait
Ior connections. Jxt aSocket is used to access
the l nput St r eamand Out put St r eamobiects
when a client connects to a Jxt aSer ver Socket (or
Ior a client to access these stream obiects when
connecting to a server). Simply put. the socket
classes let two computers communicate. (See
Eigure 1)
Eigure 1 - A user using JxtaSocket to contact to a
waiting JxtaServerSocket
In addition. the Jxt aSer ver Socket can accept
multiple connections Irom multiple computers and
create separate I/O streams Ior each one. This
allows multiple computers to be connected and
talking to a single computer. with new I/O
channels allocated Ior each inbound connection.
(See Eigure 2 Ior a three users chating scenario.)
Eigure 2 - Three peers scenario
Eigure 2 shows that each user is using a
Jxt aSer ver Socket to wait Ior connections. In
the P2P space. any one peer is usually both a client
and a server. This duality exists because oI the
distributed nature in most P2P applications. In our
chat example. the application is truly symmetric.
The chat application is always a server and becomes
a client when starting a chat with another user (such
as when User 1 contacts User 2 in Eigure 2).
Once the socket is connected. each peer has two
streams. One is based on Out put St r eamand the
other is l nput St r eam. Both streams are
connected Irom the input oI one to the output oI the
other. The chat application is now ready to pass
messages Irom either computer to the other.
Starting 3XTA
Let's now look at the example code. As mentioned.
JXTA creates a virtual overlay network. so any
application participating in the network needs to
initialize its node. connect to the network. and
announce its presence to others in the network. The
initialization process is accomplished by ioining the
net peer group. The net group is the deIault groups
all peers ioin when they connect to the JXTA
network.
Line 2 oI listing one calls newNet Peer Gr oup( ) .
Once called. several threads are started in the JXTA
platIorm to initialize connections to other peers.
(The bulk oI the classes are not shown. and some
statements -- including exceptions. logging. and
other nonessential code -- have been removed to
improve readability.)
P2P Journal. July. 2003
Page 12
Listing 1- Initializing JXTA connection using
ChatManager.startJXTA()
1: publ i c voi d st ar t JXTA( ) {
2: net Peer Gr oup =
Peer Gr oupFact or y. newNet Peer Gr oup( ) ;
3: Peer Gr oupl D peer Gr oupBi nar yl D =
MD5l D. cr eat ePeer Gr oupl D
( net Peer Gr oup. get Peer Gr oupl D( ) , " hel l o wor l d
appl i cat i on" , " chat " ) ;
4: appl i cat i onPeer Gr oup =
Peer Gr oupTool . cr eat eAndJoi nPeer Gr oup
( net Peer Gr oup, " Hel l o
Wor l d" , peer Gr oupBi nar yl D) ;
5: }
In addition to starting the JXTA platIorm. we also
need to create a context Ior us to operate within.
Line 3 creates a peer group ID using a utility class
which converts a couple oI strings ("hello world
application" and "chat") to an MD5 checksum that
is in turn is converted to a Peer Gr oupl D. On
line 4. the Peer Gr oupl D creates a peer group
which we will operate within by calling another oI
our utility classes. Peer Gr oupTool . This group
ensures that we have an isolated ID space we can
control. Peer groups in JXTA create a context that
limits messages and the scope oI services to iust
the peers that are members oI the particular group.
This scoping is similar to a subnet. but can include
any PC at any network address. Scoping also acts
as a barrier. allowing sockets to connect only
within the same group.
AIter calling startJXTA() method. we are a part oI
the JXTA virtual network and ready to set up our
socket.
The Listening Peer
To create a socket. we need an ID that can be used
to represent the chat user. In this case. we will
create an ID that is the MD5 checksum oI a name
speciIied by the user. The ID is used in a similar
way to an IP and port number Ior a traditional
socket.
At line 2 oI Listing 2. we speciIy the type oI the
pipe. The example uses the simple unicast type
because we are not worried about security. The
pipe type can be either Uni cast Type or
Uni cast Secur eType. These are the
unencrypted and encrypted versions oI messaging
in JXTA. (The Pr opagat eType is not available in
this version oI the JXTA socket API).
In line 3. we create an ID based on the name. the
type oI pipe. and a string Ior a Iunction. in this case
chat . We use the string to create a checksum that is
unique enough to avoid collisions. We are
combining the user name. a Iunction name. and the
pipe type to avoid collisions with other pipes we
may add to the application. This is the equivalent oI
IP address and port number. The ID will be
discussed later.
The class Connect i onSer ver is created on line
4. This class wraps our socket code in a thread to
allow the program to continue executing while we
wait Ior another computer to connect. In line 5. we
add a listener to be called when a computer
connects. Einally. line 6 starts the thread.
Listing 2 - Using addServer() method to start a
server waiting Ior connections.
1: publ i c voi d addSer ver ( St r i ng name) t hr ows
Except i on{
2: St r i ng t ype = Pi peSer vi ce. Uni cast Type;
3: Pi pel D pi pel D = MD5l D. cr eat ePi pel D
( appl i cat i onPeer Gr oup. get Peer Gr oupl D( ) , name,
" chat pi pe " +t ype) ;
4: Connect i onSer ver connect i onSer ver = new
Connect i onSer ver ( appl i cat i onPeer Gr oup, pi pel D,
t ype) ;
5 connect i onSer ver . addConnect i onLi st ener ( l i st ener ) ;
6: connect i onSer ver . st ar t ( ) ;
7: }
Waiting for Connections
The next step is starting the Jxt aSer ver Socket .
This is simple enough. using the peer group and pipe
advertisement as shown in the Iollowing code
Iragment Irom the Connect i onSer ver class's
constructor.
j xt aSer ver Socket = new Jxt aSer ver Socket ( peer Gr oup,
pi peAdver t i sement ) ;
Because this is a server socket. we need to wait Ior
client peers to connect. Line 5 is where the
Jxt aSer ver Socket obiect is asked to block.
waiting Ior a new connection. In Iollowing lines. the
registered listeners are called with the JxtaSocket
class. which is the handle to the connection.
Listing 3 - ConnectionServer.run() thread accepting
the connections and calling listeners.
P2P Journal. July. 2003
Page 13
1: publ i c voi d r un( ) {
2: / / St ar t wai t i ng f or connect i ons
3: whi l e ( t r ue) {
4: / / Bl ock unt i l anot her peer connect s t o t hi s
socket
5: Jxt aSocket j xt aSocket =
j xt aSer ver Socket . accept ( ) ;
6: i f ( j xt aSocket ! = nul l ) {
7: f or ( i nt i = 0; i < l i st ener s. si ze( ) ; i ++) {
8: ( ( Connect i onLi st ener ) l i st ener s. get ( i ) )
. newConnect i on( j xt aSocket ) ;
9: }
10: }
11: } / / end of whi l e t r ue
12: } / / end of met hod r un( )
The Chat Caller
The creation oI the socket Irom the client side
requires the same initial steps as Ior the server. We
use the same initialization oI JXTA. and the same
strings to designate the peer group and pipe ID
(line 3 oI Listing 4) Ior the socket creation. In Iact.
all the code is the same Ior both the server and the
client. Every peer starts a socket server and every
peer can initiate a client-side connection. This may
sound strange. But it's logical: any chatter can start
the conversation with any peer that is listening.
On line 4. we create a pipe advertisement in the
same way we did Ior the server socket. These
advertisements must match. or the client peer will
not be able to Iind the server. Line 5 initializes a
Swing GUI window to display the chat messages.
The ChatSession class on line 6 uses the window
obiect as a parameter. since the window directly
echoes messages and gets strings to send.
Listing 4 - connectToServer()
1: publ i c voi d connect ToSer ver ( St r i ng name) t hr ows
Except i on{
2: St r i ng t ype =
Pi peSer vi ce. Uni cast Type;
/ / Pi peSer vi ce. Uni cast Secur eType;
3: Pi pel D pi pel D = MD5l D. cr eat ePi pel D
( appl i cat i onPeer Gr oup. get Peer Gr oupl D( ) , name,
" chat pi pe " +t ype) ;
4: Pi peAdver t i sement pi peAdver t i sement =
Adver t i sement Ut i l i t i es. cr eat ePi peAdver t i sement
( pi pel D, t ype) ;
5: Chat Wi ndow chat Wi ndow = new Chat Wi ndow( t r ue) ;
6: Chat Sessi on chat Sessi on = new Chat Sessi on
( appl i cat i onPeer Gr oup, pi peAdver t i sement ,
chat Wi ndow, 80) ;
7: chat Wi ndow. set Vi si bl e( t r ue) ;
8: } / / End of met hod connect ToSer ver ( )
Connecting and Waiting for Data
With everything set up. we can now connect to a
server. The code is also set up to process an
incoming connection. The code in Listing 5 sets up
the I/O streams Ior either case. On line 3. we check
to see iI the value oI j xt aSocket has been
initialized. II it is null. we assume the connection is
Irom a client to a serving peer and create a new
Jxt aSocket obiect. II j xt aSocket is not null.
then we get its value Irom the socket server.
Remember that the j xt aSocket is a handle to
both the input and output streams. We get a
reIerence to these streams in lines 8 and 9. Now we
loop on the input stream. On line 14. the stream
blocks on the input stream. waiting Ior data. Note
that this is executing in its own thread to prevent the
system Irom blocking as we process the stream. On
line 16. we call the chat window with the text.
Listing 5 - ReaderThread.run(): Setup oI connection
and loop waiting on data.
1: publ i c voi d r un( ) {
2: r unni ng = t r ue;
3: i f ( j xt aSocket == nul l ) {
4: j xt aSocket = new Jxt aSocket
( appl i cat i onPeer Gr oup, pi peAdver t i sement ) ;
5: } el se {
6: / / The j xt aSocket was pr ovi ded by t he ser ver
accept ( ) .
7: }
8: out put St r eam = j xt aSocket . get Out put St r eam( ) ;
9: i nput St r eam = j xt aSocket . get l nput St r eam( ) ;
10:
11: / / Wai t i ng f or dat a now
12: buf f er = new byt e[ buf f er Si ze] ;
13: whi l e( r unni ng) {
14: i nt r ead = i nput St r eam. r ead( buf f er ) ;
15: St r i ng dat a = new St r i ng( buf f er , 0, r ead) ;
16: chat Wi ndow. appendChat Text ( dat a) ;
17: }
18: }
Creating MD5 Checksum IDs
Earlier. we created pipe and group IDs Irom MD5
checksums. As mentioned previously. a pipe ID is
similar to an IP address and port number. We use the
pipe ID because the address and port may not be
visible due to a NAT or Iirewall. In addition. the IP
address could be changed at any time by a DHCP
server. The pipe ID signiIies a logical address Ior
connection. regardless oI the true machine physical
address or its addressability.
When there are multiple peers with the same pipe
ID. the peer would be chosen randomly. This might
seem odd at Iirst. but some situations in P2P call Ior
P2P Journal. July. 2003
Page 14
a random use oI resources. A random ID is good iI
it's not important which computer you connect to.
In our case. however. the intent is to connect to a
very speciIic peer Ior a chat. Eor our pipe ID. we
will be careIul to create a unique ID. We'll use the
user's unique email address. because we need a
way to contact a speciIic person. and an ID that is
known and predictable.
A checksum or hash is used to hide the email
address and to ensure that our ID will work Ior a
large or small email address string. We always get
the same length encoding Ior any length string. We
are using MD5 hashing in this example because
we can Iit it into the UUl D l D. which is the
reIerence ID in JXTA.
There are several ways to create a predictable ID.
We can create a speciIic ID using Bi nar yl D or
the seeded UUl D implementation oI the Pi pel D .
We will use the seeded UUID. because at the time
oI this writing. Bi nar yl D is available. but not in
the current release.
To create a seeded UUl D. you create a byte array
that represents the equivalent ID. The constructor
creates a UUl D and merges the binary value to
create a valid UUID.
The method in Listing 6 creates the MD5 hash
Irom two strings. which it concatenates.
Listing 6 - generateHash(): Setup oI connection
and loop waiting on data.
1: publ i c st at i c f i nal byt e[ ] gener at eHash( St r i ng
cl ear Text l D, St r i ng f unct i on) t hr ows Except i on {
2: St r i ng i d;
3: i f ( f unct i on == nul l ) {
4: i d = cl ear Text l D;
5: } el se {
6: i d = cl ear Text l D + f unct i onSeper at or +
f unct i on;
7: }
8: byt e[ ] buf f er = i d. get Byt es( ) ;
9: MessageDi gest al gor i t hm = nul l ;
12: al gor i t hm = MessageDi gest . get l nst ance( " MD5" ) ;
13: / / Gener at e t he di gest .
14 al gor i t hm. r eset ( ) ;
15: al gor i t hm. updat e( buf f er ) ;
16: byt e[ ] di gest 1 = al gor i t hm. di gest ( ) ;
17: r et ur n di gest 1;
18: }
In Listings 7 and 8. the PeerGroupID and PipeID
are created with the hash code in the byte array.
Listing 7 - createPeerGroupID(): Create a PipeID
using the MD5 hash oI a string.
1: publ i c st at i c f i nal Peer Gr oupl D cr eat ePeer Gr oupl D(
Peer Gr oupl D par ent Peer Gr oupl D, St r i ng cl ear Text l D
St r i ng f unct i on) {
2: byt e[ ] di gest = gener at eHash( cl ear Text l D,
f unct i on) ;
3: Peer Gr oupl D peer Gr oupl D =
l DFact or y. newPeer Gr oupl D( par ent Peer Gr oupl D,
di gest ) ;
4: Peer Gr oupl D( ( Peer Gr oupl D) par ent Peer Gr oupl D, di gest ) ;
5: r et ur n peer Gr oupl D;
6: }
Listing 8: createPipeID(): Create a PipeID using the
MD5 hash oI a string.
1: publ i c st at i c f i nal Pi pel D cr eat ePi pel D( Peer Gr oupl D
peer Gr oupl , St r i ng cl ear Text l D, St r i ng f unct i on) {
2: byt e[ ] di gest = gener at eHash( cl ear Text l D,
f unct i on) ;
3: r et ur n l DFact or y. newPi pel D( peer Gr oupl D, di gest ) ;
4: }
In the Iuture. instead oI the MD5 checksum. we
could use the Bi nar yl D and SHA-1 checksum
which (as mentioned earlier) will be available in the
JXTA 2.0.X release (these are available in the
development release. but not the 2.0 stable release).
The UUl D-based IDs used in these examples are
only 128 bits. while the Bi nar yl D can be as large
as 255 bytes (2040 bits). allowing Ior a larger
unique ID.
Overview of the P2P Chat Application
Our chat application is simple. The point oI the
application is iust to demonstrate how to use
Jxt aSocket and its accompanying classes. so
there are Iew bells and whistles. Like any socket-
like application. we have both a client and a server
that waits Ior connections Irom the client. But unlike
many client-server applications. components oI both
are used. since any peer can be both client and
server. depending on who initiates a connection.
The design deIines the Iollowing classes:
· Chat Manager : Class Ior connecting to the
virtual P2P JXTA network. and Ior creating a
chat server and chat sessions.
· Chat Manager Fr ame: Erame Ior creating chat
sessions.
· Chat Wi ndow:A simple Swing window Ior the
P2P Journal. July. 2003
Page 15
· user to see input and create outputs.
· Chat Sessi on: Core code that starts a chat
connection and then handles the send/receive on
I/O streams created.
· Connect i onSer ver : This thread waits on
the socket. As other computers connect to the
socket. this class creates a new class session.
· Chat Li st ener : Used as an interIace
between the chat session and the chat window.
· Chat SendLi st ener : InterIace to link the
GUI with the session. This has a send method
used to pass the string to the session Ior
transmission.
· Connect i onLi st ener : InterIace to
announce that a new socket connection was
created.
· Peer Gr oupTool : A class oI utility methods
that create the peer group.
How 3XTA Works: Putting It All Together
The big diIIerence between the j ava. i o package
and JXTA's is that we don't use an Internet address
or a port number. since we are connecting to
personal computers that are not always addressable
(or their address changes because oI DHCP or they
could even be laptops moving between networks).
It appears that computers are all connected via the
web oI the Internet. In truth. there are many
barriers to direct connection. The obvious barriers
are Iirewalls and NATs. The Iirewall usually
blocks inbound traIIic. We can still use the web.
however. since the HTTP protocol is Iiltered so
that we receive data based on requests. Eor each
outbound request. the Iirewall allows in the
corresponding response. The NAT presents a
similar problem by hiding the IP address oI
computers in a local net and replacing it with one
external address. The NAT is used by most
companies and Internet service providers. Most
home network connections are through one or
more NAT devices.
Security is another consideration. The only
conversations that can occur when the user is
behind the Iirewall is when the user (or soItware)
initiates them. This is identical to a browser
application. The layer oI security provided by the
Iirewall is not breached.
How do any two computers isolated by Iirewalls
talk to each other? The key is that a third peer is
involved that acts as a relay. Each computer contacts
the relay to collect messages or leave them to be
accessed by the other computer. This is identical to
what happens with HTTP tunneling. but with one
little twist: The relay computer is iust another PC
someplace on the Internet. And the signiIicance is
that you don't need to have a server to have two
computers talk to each other.
In addition to HTTP. JXTA also supports TCP. II
peers can access each other directly. there is no need
Ior a relay peer. This means. oI course. a much Iaster
throughput.
Eirewalls are not the only problem. DHCP can also
cause problems by periodically changing the IP
address oI the computer. Eor the JXTA socket API.
there is an additional ID called a pipe ID. The pipe
ID acts as the socket's virtual address and port
number. JXTA's routing system connects computers
that are attempting to connect with the same pipe ID.
Eor example. iI a peer opens the Jxt aSer ver Socket
and listens Ior an ID oI 5. and another computer is
looking Ior a pipe ID oI 5. the router connects the
two. Routing and connecting two computers is too
complex to describe here. but the result is same that
the conversation can still work.
Here is a summary oI what happens when
connecting two computers. Computer A opens a
server socket with a pipe ID oI X. Computer B
opens a client socket with an ID oI X. JXTA creates
a route between A and B.
The routing between A and B calculates what relays
to use. or directly connects those two computers iI
they are on the same network.
(See http://www.ixta.org web site Ior detail).
Summary and Final Thoughts
In this article. you've seen how to create a simple
socket application on JXTA's P2P network. I also
covered a simple way to address these sockets. using
an MD5 checksum. which replaces the notion oI an
IP and port number.
As JXTA technology continues to mature. we should
expect to see a closer integration oI JXTA with
standard J2SE Java APIs. JXTA 2.0 is now easier.
Iaster. more stable. and ready Ior prime time.
Already. it is being used in many commercial
applications.
P2P Journal. July. 2003
Page 16
Copyright (c) 2002-2003
Sun Microsystems. Inc.
All Rights Reserved.
Daniel Brookshier.
the author oI book.
"JXTA: Java P2P
Programming."
Daniel is a Senior Java consultant. author. and
speaker with 20 years oI experience. Daniel's
knowledge oI soItware development covers many
industries. He is an international consultant with
assignments around the world. Daniel is the
Iounder oI Talk-Java/Drink-Java user groups in
Texas and is currently Iorming a new user group
Ior JXTA P2P developers.
P2P Journal. July. 2003
Page 17
How Peer-to-Peer Computing Helps Momentum Users Organize and
Manage Information
A White Paper by InView SoItware
June. 2003
Introduction
Touted by industry analysts as the Iuture oI the end-
user applications market. peer-to-peer (P2P)
computing lets Internet-connected users
collaborate and share inIormation more easily
right Irom their desktops. P2P computing makes
collaboration across the Internet possible; it turns
any Internet-connected PC into a virtual server so
that decentralized resources can be shared in new
ways. However. the promise oI P2P computing has
so Iar exceeded the reality. at least Ior business
users. While P2P computing has been adopted en
masse in the consumer market (Napster and
Gnutella. Ior example). widespread adoption by
businesses is slower in coming. But the tide is
turning. Businesses and business users are now
seeing the value and eIIiciency oI P2P computing.
Momentum by InView SoItware is a prime
example oI the growing acceptance oI P2P
computing by the business community. In
organizations oI all sizes. workers Iace an
onslaught oI inIormation everyday. and the volume
oI this inIormation is only expected to grow.
Increasingly. business users need soItware tools
that increase eIIiciency and productivity. make
communication and collaboration eIIortless and
seamless. and reduce costs. Additionally. business
users need an easy way to manage and share their
documents and tasks. Eor organizations looking to
do all this. Momentum is the cost-eIIective choice.
Momentum: A Brief Overview
Momentum 1.0 is a Shared InIormation Manager
(SIM) Ior both the Windows and Linux operating
systems that helps individuals and teams better
organize their daily activities. documents. and data.
Users create workspaces containing documents
that they would like to share and then invite other
users to ioin that workspace. Momentum users can
work collaboratively on documents such as
drawings. charts. timelines. and outlines using
Momentum's built-in instant messaging. real-time
collaboration capabilities. change notiIications. and
document versioning.
Feature Highlights
§ A distributed computing environment centered
around workspaces
§ Real-time collaboration and multi-user
editing/viewing
§ A drawing editor
§ An outliner and task manager
§ Instant messaging
§ Document versioning
§ Change notiIications
§ Peer-to-peer messaging
§ Integration with MicrosoIt OIIice. StarOIIice.
OpenOIIice. and Adobe Acrobat
The Communication Challenge
As knowledge workers struggle to manage their daily
communications and inIormation Ilow. they Iace
many challenges. Eirst and Ioremost is the sheer
volume oI inIormation and communications
knowledge workers must process everyday. And the
volume is growing rapidly. According to Eorrester
Research. content volume is growing by more than
200° each year. which means workers must process
a growing amount oI data.
Increasingly. much oI this communication both
inside and outside the organization is via e-mail. It's
no surprise to anyone that the amount oI e-mail
traIIic is increasing. Additionally. e-mail message
now oIten contain document attachments. So. in
addition to reading and responding to the e-mail
which oIten has a lengthy distribution list workers
must now also read. edit. re-distribute. and organize
the document attachments they receive. Document
management even simple document versioning
becomes a nearly impossible task. particularly when
P2P Journal. July. 2003
Page 18
interacting with customers. suppliers. and business
partners outside the organization. And. it is a
problem that is only going to get worse as the
volume oI inIormation and communications
continues to grow.
Clearly. new ways oI managing inIormation and
communications are needed to give knowledge
workers a Iighting chance to keep up with the
inIormation overload they increasingly Iace.
Workers need easy-to-install. easy-to-use tools that
work with the soItware applications they are
already using so they can access the inIormation
they need without getting bogged down by
inIormation overload.
But. it's not iust a matter oI accessing the right
inIormation; knowledge workers must be conIident
they are accessing the right up-to-date inIormation.
And doing so must be automatic: Workers should
not have to exert any extra eIIort to ensure the
inIormation they are accessing is up-to-date; the
soItware should do that Ior them. iust as it should
notiIy them when inIormation they have an interest
in is modiIied.
Einally. inIormation sharing oIten reIerred to as
collaborating must be seamless. eIIortless. and
secure. Collaborating with co-worker or business
partner across the country should not be any more
diIIicult than collaborating with a co-worker or
business partner across the hall. In Iact. geographic
location as well as network conIiguration should
be transparent to the end user. In other words. the
collaboration soItware should iust work.
Collaboration: Managing Information,
Not 3ust Communicating It
Collaboration is about more than iust managing
communications; it is about managing information.
Whether done in real time or asynchronously.
collaboration communicates. inIorms. and
organizes. It can take many Iorms: text chat.
messaging. real-time or asynchronous document
editing and viewing. document versioning. change
notiIications. and document management. to name
iust a Iew.
What diIIerentiates P2P collaboration is how it
decentralizes the management oI inIormation. Peer
devices communicating directly with each other Ior
example. personal computers connected to the
Internet is incredibly empowering Ior end users. It's
even more compelling when P2P computing can
happen seamlessly and eIIortlessly Ior end users
without requiring knowledge oI network protocols
and other technical details. In such an environment.
end users can communicate with each other and
exchange inIormation in other words. collaborate
on an ad hoc and as-needed basis. With the right
soItware tools. Iorming a proiect team. Ior example.
can be done in an instant. regardless oI the
geographic location oI the team members or the
diverse network environments to which they are
connected.
This decentralization oI inIormation management.
particularly when geographic locations and network
environments are transparent. can be a maior
productivity booster. End users can quickly and
easily access. view. and modiIy the inIormation that
matters to them while Iiltering out the inIormation
that doesn't. And all this can happen at the end-user
level. without requiring involvement oI already-
overworked IT staIIs.
In organizations both large and small. P2P
computing gives end users a weapon to beat back the
onslaught oI inIormation by providing a computing
approach that gives the end user ultimate control:
P2P computing is by its nature direct and targeted; its
Iiltering capabilities are built-in.
That is welcome news indeed in today's inIormation-
rich workplace.
Momentum's Unique Implementation of
P2P Computing
P2P Communication and Client-Server Data
Storage
By combining peer-to-peer communication. desktop
soItware's ease oI installation and use. and client-
server data storage. Momentum 1.0 is the Iirst oI a
new breed oI distributed desktop soItware
applications. Momentum leverages advances in P2P
communication to allow users to collaborate and
discover each other automatically and transparently
crossing Iirewalls.
P2P Journal. July. 2003
Page 19
Momentum adheres to the client-server model with
respect to creating. viewing. and storing data. Core
to Momentum's data management (creating.
viewing. and storing data) are Momentum
workspaces. A workspace can be created on any
machine desktop. laptop. or server and is a
collection oI various data types such as Iolders.
documents. and members (contacts). All data Ior a
given workspace resides in a database on the
computer where the workspace was created. In this
respect. the computer where the workspace was
created acts a server. Momentum (acting as a
client) lets users create. edit. and view data iust like
the desktop applications they are currently using.
Regardless oI the physical location oI the computer
where a workspace resides. Momentum's powerIul
communication technology ensures users can
access the workspace data. And users can continue
to work while disconnected Irom the network or
Internet. Changes are easy to check in upon
reconnection.
Momentum's Collaboration Feature Set
Auto-discoverv of Momentum Users on the Local
Area Aetwork (LAA}
Momentum users automatically Iind each other on
the LAN. To see which local users are online. users
click on the Local Network Users shortcut in
Momentum's Workspace Window or navigate to
the Local Network Users Iolder under the Contacts
Iolder in the Navigation pane. Erom there they
have access to all oI the users on the LAN who are
running Momentum to initiate an instant message
(text chat) session. send a P2P message. or send a
Momentum workspace invitation.
Peer-to-Peer and Outbound SM1P Messaging
Momentum users can send email-like messages to
other users. The destination oI a message can be
one or more Momentum contacts or standard email
addresses. Hyperlinks in the messages are
supported.
Instant Messaging / 1ext Chat
Users can start up a real-time chat session with
other users in their Momentum contact lists. Any
user who is part oI the chat session can invite other
users into the session. The session is Iully
decentralized. which allows participants to leave the
session. even turning their machines oII. while the
rest oI the group continues to chat.
Sharing Workspaces with Other Users
Users can create named workspaces on their
machines as repositories Ior various data types such
as Iolders. versioned documents. members
(contacts). and messages. Other Momentum users
can be granted access to a workspace by sending
them a workspace invitation via Momentum's P2P
messaging or standard email. The invitation
recipients import the invitation. and depending upon
security settings. gain access to the workspace.
Once users gain access to a workspace. the
workspace displays in the remote users' Navigation
panel. where they can create Iolders.
add/modiIy/delete documents. and view the members
list (a list oI Momentum users who have access to
the workspace).
Change Aotifications
Users can conIigure Momentum so they receive
automatic notiIications oI changes to workspaces and
documents. Eor example. when a user edits a
drawing and clicks the Save button. the user is
prompted to enter a revision comment. The
document is then saved as a new version. and a
notiIication is automatically sent to subscribers. The
notiIication includes the revision comment typed in
by the user and a hyperlink to the modiIied
document. NotiIications are delivered via P2P
messages or standard email.
Real-time Collaboration on Momentum Documents
(Drawings and Outlines}
Users can collaborate in real time on native
Momentum documents (drawings and outlines). To
start a collaboration session. a user simply opens a
document. II other users have the document open. or
iI other users open the document later. they will
automatically be part oI the collaboration session.
Once part oI a collaboration session. users can co-
edit the document and chat with each other using the
integrated chat Ieature in Momentum's document
editors. The chat session is saved as part oI the
document version.
P2P Journal. July. 2003
Page 20
Conclusion
Improved communication, simplified information
management, greater productivitv
With P2P computing gaining acceptance by
businesses. a new and welcome way to manage
inIormation is emerging Ior mainstream business
users. The advantages oI P2P computing are
numerous:
§ Direct. targeted communication
§ Built-in inIormation Iiltering
§ End-user empowerment
§ Transparency across geographies and diverse
network environments
§ Seamless and eIIortless collaboration
And the beneIits derived Irom P2P computing are
both signiIicant and simple: more work gets done
Iaster. and it gets done right.
Eor these reasons. Momentum was built Irom the
ground up with P2P computing and its beneIits in
mind.
(A screenshot oI Momentum's Workspace window
is on the next page.)
InView Software is an exciting new software
company that is creating new technoIogies and
products for users to capture, convey, and exchange
information. Its fIagship product - Momentum
faciIitates coIIaborative computing for users and
improves workpIace productivity through a rich user
experience. Momentum uses JXTA technoIogy for P2P
computing.
P2P Journal. July. 2003
Page 21
Eigure 1: A screenshot oI Momentum's Workspace Window shows Momentum's integration with StarOIIice.
OpenOIIice. MicrosoIt OIIice. and Adobe Acrobat via WebDAV (Web Distributed Authoring and Versioning).
P2P Journal. July. 2003
Page 22
Get Momentum Today!
Momentum is a new cross-platform Shared lnformation Manager (SlM) that helps individuals and teams better organize
their daily activities, documents, and data.
Momentum, which runs on both Windows and Linux, keeps co-workers, customers, and business partners informed
and up-to-date by coupling peer-to-peer communications with familiar desktop software capabilities.
Feature highIights:
- A distributed computing environment centered around workspaces
- Real-time collaboration and multi-user editing/viewing
- A drawing editor
- An outliner and task manager
- lnstant messaging
- Peer-to-peer messaging
- Document versioning
- Change notifications
- lntegration with Microsoft Office, StarOffice, OpenOffice, and Adobe Acrobat
Limited Time Offer!
Now you can get a 5-user pack of Momentum (Windows, Linux, or a combination) for an additional $100 off the already
low price of $99 per user ($495). When ordering please use promotional code 2832.
This offer won't last long. Visit our Web site at www.lnViewSoftware.com or call us at 1-866-468-4391 to get Momentum
today!
Momentum: the cross-platform Shared Information Manager (SIM)
P2P Journal. July. 2003
Page 23
CaII for Paper
Dear Iriend:
The Peer-to-Peer Journal (P2PJ) is a bi-monthly iournal that opens a Iorum to individuals and hi-
tech Iirms who/which are interested in applying. developing. educating. and advertising in the
Iields oI Peer-to-Peer (P2P) and parallel computing. P2P Journal intends to be the gathering
place Ior people interested in reading and writing articles or discussing and chatting about P2P.
instant messaging (IM). collaborative computing. Iile sharing & distribution tools and protocols.
and parallel computing topics. such as grid and cluster. Experts or people who are directly
engaged in those the Iields could contribute articles in P2PJ.
The Editor-in-chieI is now inviting you or your Iriends to submit papers or letters Ior publication
at P2PJ. Articles. whitepapers. product reviews. discussions. and letters or short communications
to iournal are accepted. Eor writer's guideline. see
http://p2piournal.com/main/p2p_writers_guideline.pdI
Once an article is accepted Ior publication. P2P Journal retains its copyrights. although
contributors may get a written permission Irom P2PJ Ior quotation or reuse his/her articles Ior
non-proIit purpose.
P2PJ shall become a medium helping connect people and entities and disperse useIul
inIormation. We believe that through building a gathering place where people can exchange
ideas and inIormation. everyone will beneIit Irom it. In the spirit oI sharing and Ireely
exchanging ideas. P2PJ has an online chat room that allows instant communication between
online visitors.
P2PJ encourages every contributor to attach his/her passport photo to the article as well as a
short bio. That way it can increase the author's visibility. We may also give some valuable giIt to
contributors Ior the recognition Ior his/her contribution to P2P computing Iields.
Best regards.
Raymond E. Gao
Editor-in-ChieI. P2P Journal
by Mema Roussopoulos & Mary Baker
This articles talks about CUP (Controlled Update Propagation) technology Ior
Peer-to-Peer (P2P) network.
by Raymond Gao
This article talks about various P2P security and trust mechanism, i.e. encryption,
digital certiIicate, PKI, Poblano's model, etc.
by Daniel Brookshier
This article demonstrates how to use JXTA to build a remote display application,
called JXTA Remote Desktop (JRD).
Use P2PJ's message board Ior all discussion related to this issue.
Cover Image: A mural painting Irom the Long Corridor in the Grand Palace, Bangkok,
Thailand. This is Irom the story oI Ramayana, about battles between
humans and gods.
Editor-in-ChieI: Raymond Gao, raygao(attbi.com
JXTA Track Editor: Daniel Brookshier, turbogeek(cluck.com
Contributing Editors: Mema Roussopoulos, Mary Baker
Website Assistant: Jerry Giant, iariarbinkx(yeah.net
P2P Journal is currently accepting articles Ior November Issue
Copyright 2003: Unless with explicit written permission IromP2P Journal, no part oI this iournal
may be recycled or reproduced in whole or parts.
eptember, 2003, P2P Journal
Mema Roussopoulos Mary Baker
Harvard Universitv HP Laboratories
Abstract
As peer-to-peer networks become more popular, the
use oI metadata to achieve a variety oI tasks (e.g. loca-
ting content, pricing, auctioning) becomes more
important. In this paper, we report that propagating
updates to cached metadata with moderation is a
mechanism that provides beneIits beyond simple
caching with a Iixed expiration. owever, such a
mechanism re uires using application-speciIic and or
incentive-based policies to moderate this propagation.
We describe issues involved in perIorming such
propagation, and provide examples where we have
experimental evidence showing beneIits oI the
metadata update propagation technologies, as well as
propose potential situations where it could be
beneIicial.
I. INTR DUCTI N
As peer-to-peer networks gain more interest, the
use oI metadata to achieve certain tasks becomes
more important. or example, one oI the Iundamental
operations in current popular peer-to-peer networks
is the task oI locating content: given the name or a
set oI keyword attributes oI an obiect oI interest, how
do you locate the obiect within the peer-to-peer
network Many peer-to-peer networks push a set oI
metadata in response to a search uery gnu ,
R 0 , MK 0 , RD0 , ZKJ0 . This
metadata typically consists oI index entries that point
to the locations oI nodes that serve replicas oI the
content oI interest, but could also include other in-
Iormation such as pricing, reputation or load inIor-
mation oI these serving nodes.
The peer-to-peer model assumes that the global set
oI valid metadata (index entries, pricing, etc.) will
change constantly as peer nodes ioin and leave the
network and content is continuously added to and
deleted Irom the network. Nodes that use metadata
to serve ueries in a more timely Iashion need to
know about changes to the metadata to perIorm well.
Well is an application-dependent attribute, and
could Ior example mean Iaster content download
time or higher integrity oI downloaded content.
Keeping cached metadata up-to-date re uires
tracking which metadata items change, as well as
tracking when interest in updating particular items at
each cache has died down so as to avoid unnecessary
update propagation.
In this paper, we argue that in a peer-to-peer
network, controlled propagation oI updates to cached
metadata provides signiIicant beneIits beyond simple
caching with a Iixed expiration although, doing so, it
re uires application-speciIic incentive-based policies
to moderate this propagation. These policies cannot
be assumed to be universally applicable to all peers
since each peer will have diIIerent capacity and or
motivation Ior participation in the peer-to-peer
application.
ur work with CUP RB03 , a protocol Ior per-
Iorming Controlled Update Propagation in a
peer-to-peer network has allowed us to explore this
possibility. CUP asynchronously builds caches oI
metadata while answering search ueries. It then
propagates updates oI metadata to maintain these
caches. A key Ieature oI CUP is that it allows nodes
to use their own incentive-based policies to
determine when to receive and when to propagate
updates.
We describe how CUP works and give a couple oI
examples where the use oI CUP to propagate meta-
data updates has been very beneIicial. peciIically,
we Iirst describe how CUP can be used to maintain
caches oI index entries, since this is the metadata
many researchers have recently advocated caching
(e.g. R 0 , MK 0 ). We show that by using
propagation policies where the incentive to cut oII
propagation is popularitv-driven. CUP can greatly
reduce the average search uery latency while re-
covering update propagation overhead. We then de-
scribe how we have leveraged CUP to deliver meta-
data re uired Ior eIIective load-balancing oI content
demand across replica nodes.
We also describe other kinds oI metadata that
could be propagated and other kinds oI incentives
that could drive the propagation decision including
eptember, 2003, P2P Journal
2
capacitv-driven and value-driven incentives. ur
main goal here is to present evidence that controlled
propagation oI metadata updates is crucial and to open
discussion on potential new peer-to-peer services where
we can use such a technology.
II. T E CUP PR T C L
We now describe how CUP works using the example
oI maintaining caches oI index entries. CUP is not tied
to any particular search mechanismand thereIore can be
applied in both networks that perIorm structured search
as well as networks that perIormunstructured search. In
this paper, we will describe how CUP works Ior
structured peer-to-peer networks. In structured search,
ueries Iollow a well-deIined path Irom the uerying
node to an authority node that holds the index entries
pertaining to the uery R 0 , RD0 , MK 0 ,
ZKJ0 .
The basic idea oI CUP is that every node in the
peer-to-peer network maintains two logical channels
per neighbor: a uery channel and an update channel.
The uery channel is used to Iorward lookup ueries Ior
content oI interest to the neighbor that is closest to the
authority node which holds the entries Ior that content.
The update channel is used to Iorward uery responses
asynchronously to a neighbor. These uery responses
contain sets oI index entries that point to nodes holding
the content in uestion. The update channel is also
used to update index entries that are cached at the
neighbor.
igure shows a snapshot oI CUP in progress in a
network oI seven nodes. The Iour logical channels are
shown between each pair oI nodes. The leIt halI oI each
node shows the set oI content items Ior which the node is
the authority. The right halI shows the set oI content
items Ior which the node has cached index entries as a
result oI handling lookup ueries. or example, node A
is the authority node Ior content K3 and nodes C, D, E,
, and G have cached index entries Ior content K3. The
process oI uerying and updating index entries Ior a
particular content KIorms a CUP tree whose root is the
authority node Ior content K. The branches oI the tree
are Iormed by the paths traveled by lookup ueries Irom
other nodes in the network. or example, in igure ,
node Ais the root oI the CUP tree Ior K3 and branch { ,
D, C, A} has grown as a result oI a lookup uery Ior
K3 at node .
ig. . CUP Trees
Node A is the authority Ior content K3. It knows the
location oI all content replica nodes that serve content
K3. Replica nodes Iirst send birth messages to authority
A to indicate they are serving content K3. They may
also send periodic reIreshes or invalidation messages to
A to indicate that they are still serving or no longer
serving the content. A then Iorwards on any birth,
reIresh or invalidation messages it receives, which are
propagated down the CUP tree to all interested nodes
in the network. or example, in igure any update
messages Ior index entries associated with content K3
that arrive at A Irom replica nodes are Iorwarded down
the K3 CUP tree to C at level , D and E at level 2, and
and G at level 3.
The cascaded propagation oI updates Irom authority
nodes down the reverse paths oI search ueries has
many advantages. irst, updates extend the liIetime oI
cached entries allowing intermediate nodes to continue
serving ueries Irom their caches without re-issuing
new ueries. It has been shown that up to IiIty percent
oI content hits at web caches are Ireshness misses ,
i.e., instances where the content is valid but stale and
thereIore cannot be used without Iirst being
re-validated CK0 . econd, a node that proactively
pushes updates to interested neighbors reduces its load
oI ueries generated by those neighbors. Third, the
Iurther down an update gets pushed, the shorter the
distance subse uent ueries need to travel to reach a
Iresh cached answer. As a result, uery response
latency is reduced.
A. Popularitv-Driven Incentives
In CUP, nodes are Iree to use their own
incentive-based policies to determine when to
eptember, 2003, P2P Journal
3
propagate and when to receive updates. The
incentive depends on the application goals and the
metadata being updated. In the case oI updating index
entries, we have extensively studied policies using
popularitv-based incentives RB03 . These are
policies where the incentive to receive index updates
Ior a particular content item depends on the Ire uency
oI ueries Ior that item. The higher the Ire uency, the
greater the incentive to receive updates Ior that item.
ThereIore, by pushing popular index updates to
neighbors, the node saves itselI Irom getting ueries
Irom those neighbors.
Popularity-based propagation policies aim to
moderate the update overhead, i.e., the number oI
network hops traveled by updates. We brieIly de-
scribe the cost model we use when analy ing the
perIormance oI CUP under these policies, and we
present some experimental evidence that such poli-
cies greatly reduce the average search uery latency
while at the same time recovering propagation over-
head.
Consider a node A that is the authority Ior content
K and consider the tree generated by issuing a uery
Ior K Irom every node in the peer-to-peer network.
The resulting tree, rooted at A, is the spanning tree
Ior K, (A, K). This tree contains all possible uery
paths Ior K. We deIine cost in terms oI network hops
traveled. rom a node N's perspective, the cost oI a
uery Ior K that incurs a cache miss at N is two hops,
one hop to push the uery up to N's parent and one
hop to push the answer down to N. The cost oI an
update Ior K is one hop to receive the update Irom
N's parent.
The propagation oI an update Ior K to a node N is
fustified iI its cost is recovered by a subse uent
uery arriving in the spanning subtree below N. or
each hop a iustiIied update u is pushed down to the
root N oI subtree (N, K), exactly one hop is saved
since without u 's propagation, entries in all nodes oI
(N, K) will expire simultaneously and the Iirst sub-
se uent uery landing at a node N
i
in (N,K) within
u's expiration will cause two hops, IromNto its parent
and back. This halves the number oI hops traveled
between N and its parent which in turn reduces uery
latency. In Iact all subse uent ueries posted
somewhere in (N, K) beIore u´s expiration will ben-
eIit Irom N receiving u. Thus, the beneIit oI a
We assume uery responses Ilow down and are cached along the
reverse uery path. The cost model changes slightly iI uery responses
Ilow directly Irom the authority node to the original uerying node.
iustiIied CUP update goes beyond iust recovery oI
its cost.
The cumulative beneIit an update u brings to sub-
tree (N, K) increases when N is closer to the au-
thority node since there is a higher probability that
ueries will be posted within (N, K). We deIine
investment return as the cumulative savings in
hops achieved by pushing an update to N. As long as
the investment return is greater than , CUP Iully
recovers its overhead.
To moderate propagation, we have explored two
kinds oI popularity-based policies: probabilistic and
history-based. In the probabilistic policy, a node de-
termines iI a received update is iustiIied by calcu-
lating the chances a uery will arrive somewhere in
its subtree to recover the cost oI the update. In the
history-based policy, a node determines iI an update
is iustiIied by comparing the ratio oI uery arrival
rate to update arrival rate in a sliding window oI the
last n update arrivals. II the ratio oI ueries to up-
dates is greater than some threshold, the update is
deemed iustiIied. In either oI the two policies, iI the
update is not iustiIied, the node cuts oII its intake oI
updates.
We have Iound that both types oI popularity-based
policies bring beneIits. or example, when n ÷ 2,
the history-based policy can reduce search latency
by as much as an order oI magnitude when compared
with path caching with Iixed expiration RB03 . ur-
thermore the update overhead this policy incurs is
more than compensated Ior by its investment return.
We see this in igure 2 which shows the overall in-
vestment return Ior increasingly large networks and
Poisson uery arrival rates oI , 0, 00, and 000
ueries per second. rom the Iigure we see that Ior a
particular network si e, iI we increase the uery rate
the investment return increases, and Ior a particular
uery rate, iI we increase the network si e, the
investment return also increases. This demonstrates
that CUP can scale to higher uery rates and higher
network si es.
B. Load-Balancing Incentives
aving seen the beneIits index updates bring, we
have used the CUP protocol to study the problem
oI load balancing in a peer-to-peer network where
the goal is to distribute the demand Ior a particular
content Iairly across the set oI replica nodes that
serve that content. In the literature, little Iocus has
been given on how an individual node should choose
eptember, 2003, P2P Journal
ig. 2. Investment return vs. net si e. (Log-scale axes.)
among the set oI index entries returned by a search
uery to Iorward client re uests. This choice is im-
portant because peer nodes tend to be heterogeneous
GG02 and some replica nodes will tend to have
more capacity to satisIy re uests Ior content than
others. II nodes choose Irom the returned index en-
tries careIully, the system can serve content in a more
timely Iashion by directing content re uests to more
capable replica nodes.
Previous load-balancing techni ues in the lit-
erature base their decisions on periodic or con-
tinuous updates containing inIormation on load
(e.g. GC , Mit or available capacitv (e.g.,
Z Z . We have leveraged the CUP protocol to
deliver load-balancing metadata to see the eIIicacy
oI these algorithms when applied in a peer-to-peer
context.
The incentive Ior a node N to receive a
load-balancing update is driven by two Iactors: the
popularity oI the particular update at the subtree
below N and how well the update contributes to
balancing the demand Ior content across the set oI
replica nodes. By receiving a load-balancing update
Ior a popular item, N not only beneIits the replica
nodes serving the content, but beneIits itselI as well.
This is because without accurate load-balancing
inIormation, N might point clients to an overloaded
replica. AIter Iailing to obtain the desired content
Iromthe replica, clients would then uery N again Ior
a diIIerent replica. N could thus save itselI Irom
getting such re-try ueries iI it receives the appropriate
load-balancing updates.
When applied in a peer-to-peer context, each up-
date propagated by previously proposed algorithms
heavily depends on preceding updates propagated.
or example, iI some replicas report a high
available capacity, this may cause peer nodes to
Iorward an unpredictable number oI re uests to these
replicas causing them to overload. The shiIt oI the
workload to these replicas increases the available
capacities oI other replicas who report higher
availability at the next propagation causing re uests
to Ilock to them instead. This load oscillation can
occur even when the workload re uest rate is as low
as 0 oI the total capacities oI the replicas.
To avoid oscillation, we developed a new
load-balancing algorithm, Max-Cap, that makes
decisions based on the inherent maximum capacities
oI the replica nodes. We deIine maximumcapacity as
the maximum number oI content re uests per time
unit that a replica claims it can handle. The maximum
capacity is like a contract by which the replica
agrees to abide. II the replica cannot sustain its
advertised rate, then it may choose to advertise a
new maximum capacity, which is propagated down
the CUP tree. Max-Cap does not suIIer Irom load
oscillations as previous techni ues do because the
load-balancing updates it sends are independent oI
each other. Moreover, experiments show that
Max-Cap incurs less propagation overhead than
previous algorithms since load-balancing updates are
only propagated when replicas choose to change their
contracts or when replicas enter or leave the network
Rou02 .
We cite our load-balancing work with CUP as
more evidence that propagation oI metadata updates
can be beneIicial in that it provides the opportunity to
achieve better application perIormance in a
peer-to-peer network. In this case, better application
perIormance means Iaster content transIer. owever,
this work is also an example oI how controlled
propagation oI updates is necessary. Propagating all
load-balancing updates as done by previously
proposed algorithms which are based on available
capacity does not guarantee good load-balancing
perIormance in a peer-to-peer network. Max-Cap
propagates load-balancing metadata updates in
moderation, and it is this moderation we advocate
here.
III. T ER INCENTI E
Nodes may not always be able to propagate all up-
dates to all interested neighbors. When a node's out-
eptember, 2003, P2P Journal
going capacity is limited, the incentive to propagate
is capacitv-driven. In this case, the cost model we
introduced in ection II-A is extended to include the
node's propagation capacity. or example, suppose a
node N receives an update to be propagated to each
oI its child neighbors but N only has capacity to prop-
agate to one oI the children. The child, C, most iusti-
Iied in receiving this update is the one whose subtree
(C, K) will reap the largest investment return Irom
receiving the update.
There are many other examples oI possible
capacity-driven propagation behavior. A node may
Iavor pushing updates to neighbors that have higher
connectivity over neighbors with lower connectivity.
A node may Iavor neighbors that have been a good
source oI iustiIied updates over neighbors that are
less reliable or less cooperative. r still a node may
treat all neighbors e ually but choose to re-order up-
dates such that updates that provide higher beneIits
are pushed out Iirst. or example, a node may push
out older updates ahead oI others that have more time
leIt beIore they expire.
B. Metadata-Jalue-Driven Incentives
CUP can be leveraged to propagate other kinds oI
metadata as well. or example, the authority nodes
could propagate prices advertised by replicas Ior ser-
vices they oIIer. As the replica nodes change their
oIIered price, the price updates could be propagated
down the CUP trees to interested nodes. Replica
prices may be a Iunction oI the replica's current con-
nectivity, load, or even the willingness oI the replica
to provide service. Clients then choose Irom amongst
the replicas depending on the oIIered price adver-
tised.
2
ere, the incentive a node uses to cut oII incoming
price updates may be both popularity-driven as well
as metadata-value-driven. ome kinds oI metadata,
such as price inIormation may change Ire uently
enough that receiving an update Ior every change is
neither necessary nor desired. Whereas
popularity-driven incentive policies mainly aim to
reduce network overhead, value-driven incentive
policies aim to reduce overhead incurred in
processing and Iiltering unwanted or irrelevant
Iine-grained updates. Depending on the application,
this overhead might consume computer resources
(e.g., CPU, battery, etc.) but more importantly, may
2
Connectivity and load inIormation could be advertised by replicas
and used together with price inIormation in the client decision.
also consume human resources (iI the Iiltering
re uires manual user intervention). The beneIit oI a
iustiIied update is thus not only reduced network hops
traveled, but also reduced computer human resources.
The cost model oI ection II-A must thereIore take
these into account as well.
alue-driven incentives to receive updates work
much like current publish-subscribe applications,
where subscribers indicate their interest in particular
events or items (e.g., RKCD0 ). or example, a
leaI node, N, may inIorm its parent that it would only
like to receive price updates Ior replicas whose
advertised price is less than some maximum value
set by N's local clients. This way N's parent will
not propagate updates Ior replicas whose service can-
not be aIIorded by N's clients. uch a condition set
at a leaI node would be propagated upward toward
the authority root node. That is, a non-leaI node
would cut oII its intake oI updates Ior replicas whose
price exceeds the maximum price allowed by its local
clients and the clients oI nodes in the subtree below
it.
Metadata update propagation can also enhance
auctioning or bidding Ior service within a
peer-to-peer network CGM02 . Replicas that provide
a particular service and receive bids Ior that service,
can propagate these bids down the CUP tree. Nodes
with clients interested in bidding Ior service ioin the
CUP tree to receive these bid updates, allowing
clients to set their bids accordingly. A variation oI
this bidding scenario is to have nodes with clients
interested in bidding Ior service push updates to the
authority node. The authority node then propagates
these bid updates down the tree to serving nodes that
are interested in providing the service.
As a Iinal example, metadata update propagation
can also enhance the integrity oI content that is ex-
changed in a peer-to-peer network. Clients that re-
ceive service Irom replica nodes could report to au-
thority nodes about the uality oI the service received
and this reputation inIormation could be propagated
down the CUP tree in eIIort to identiIy replica nodes
that serve content cooperatively and with integrity.
I . DI CU I N
In this paper, we discussed that propagation oI
metadata updates can be very beneIicial in a
peer-to-peer network. owever, this propagation
should be controlled and guided by individual
incentive-based policies. We proposed CUP, a pro-
eptember, 2003, P2P Journal
tocol Ior propagating metadata updates that allows
peer nodes to use their own incentive-based policies
to control update propagation. We presented a
couple scenarios oI moderated propagation and their
experimentally measured beneIits. We also
described other potential applications that can use
CUP technology. We hope this article opens up
discussion Ior new services that can be provided in a
peer-to-peer network through eIIective propagation
oI metadata updates.
RE ERENCE
CGM02 B. . Cooper and . Garcia-Molina. Bidding Ior stor-
age space in a peer-to-peer data preservation system. In
ICDCS. 2002.
CK0 E. Cohen and . Kaplan. ReIreshment Policies Ior Web
Content Caches. In INFOCOM. 200 .
GC Z. Geneva and K. J. Christensen. Challenges in URL
witching Ior Implementing Globally Distributed Web
ites. In Workshop on Scalable Web Services. 2000.
gnu The Gnutel la Pr ot ocol peci Ii cati on v . .
http: gnutella.wego.com .
Mit M. Mit enmacher. ow UseIul is ld InIormation In
PODC. .
RB03 Mema Roussopoulos and Mary Baker. CUP: Controlled
Update Propagation in Peer to Peer Networks. In Pro-
ceedings of the 2003 USENIX Annual 1echnical Confer-
ence. June 2003.
RD0 A. Rowstron and P. Druschel. Pastry: calable, dis-
tributed obiect location and routing Ior large-scale
peer-to-peer systems. In Middleware. November 200 .
R 0 . Ratnasamy, P. rancis, M. andley, R. Karp, and .
henker. A calable Content-Addressable Network.
InSIGCOMM. 200 .
RKCD0 A. Rowstron, A. Kermarrec, M. Castro, and P. Druschel.
CRIBE: The design oI a large-scale event notiIication
inIrastructure. In NGC. 200 .
Rou02 M. Roussopoulos. Controlled Update Propagation in
Peer-to-Peer Networks. PhD thesis, tanIord Univ., 2002.
GG02 . aroiu, P. K. Gummadi, and .D. Gribble. A Mea-
surement tudy oI Peer-to-Peer ile haring ystems. In
MMCN. 2002.
MK 0 I. toica, R. Morris, D. Karger, . Kaashoek, and .
Bal-akrishnan. Chord: A calable Peer-to-peer Lookup
ervice Ior Internet Applications. In SIGCOMM. 200 .
ZKJ0 B. . Zhao, J. D. Kubiatowic , and A. D. Joseph.
Tapestry: An InIrastructure Ior ault-tolerant Wide-area
Location and Routing. Technical Report
UCB C D-0 - , U. C. Berkeley, April 200 .
Z Z . Zhu, T. ang, . Zheng, D. Watson, . . Ibarra, and
T. mith. Adaptive load sharing Ior clustered digital li-
brary services. In HPDC. .
Mema Roussopoulos is
an Assistant ProIessor
oI Computer cience on
the Gordon McKay
Endowment. BeIore
ioining arvard, she
was a Postdoctoral
ellow in the
Mos uitoNet Group at
tanIord University.
he received her PhD
and Master's degrees in
Computer cience Irom tanIord, and her
Bachelor's degree in Computer cience Irom the
University oI Maryland at College Park. er
interests are in the areas oI distributed systems,
networking, and mobile and wireless computing.
er e-mail is: mema(cs.stanIord.edu
eptember, 2003, P2P Journal
Raymond Gao
mailto:raygao(comcast.net
ecurity and trust are key topics Ior
peer-to-peer (P2P) computing. Peers in the P2P
network can play complimentary roles, servers,
routers, and clients. Contents may originate Irom
edge peers. Using transient and sometimes mutual
beneIicial relationships, inIormation are shared
and, metadata are repopulated throughout the
network. Peers, super-peers, and relay-peers are
loosely associated with each others. Under the
P2P computing paradigm, relationships are oIten
short-lived and unstable.
or corporate IT departments, security is a top
priority and, they want to mitigate risk. Thus, it is
important Ior P2P computing to develop ade uate
security Irameworks beIore it becomes embraced
by enterprises.
ow to establish identity, to build trust, to
assess risk, and to discuss best practices are
essential discussions Ior P2P security.
P2P computing is volatile. Its transient nature
makes security management a complex task and a
network administrator`s iob complicated. It is
particularly diIIicult to establish a good security
Iramework. Even without P2P, many companies
have experienced security breaches, virus-attacks,
and inIormation theIt through unmanaged
backdoors and loopholes.
ecurity risks can come in a myriad oI Iorms
and aIIect Irom a Iew systems to halt the entire
enterprise. ome examples are listed below:
irus iruses and Troian horses have
always been headaches Ior corporate IT
departments. By nature, P2P connections are
transitory. Relationships are loosely woven and
oIten unmanaged. Unsavory individuals entities
can exploit this weakness to seed the network
with malicious contents. Because it is virtually
impossible to set up a uniIorm security policy or
model Ior the entire P2P network, isolating or
uarantining virus inIections are rather
challenging chores. And, potentials Ior inIection
and repeat-inIections are high. Unchecked
viruses and or Troian horses can spread uickly
to become epidemics, like wildIires.
Bug oItware bugs can be attributed to a
variety oI reasons, insuIIicient architecture
consideration, programming errors, unexpected
user behaviors, application conIlicts, or run-time
environment issues, like hardware, , network,
storage, etc. Although most bugs tend to have
trivial aIIect on the network, nevertheless, they
can still hose primary servers, resulting in
service degradation or even hanging the network.
An example architecture bug is using ping to
detect and to stay in sync with other peers. When
there are too many concurrent users or a sudden
surge oI new peers who are ioining
simultaneously, the P2P network could be
Ilooded by ping re uests.
Bandwidth clogging Every network has a
physical transmission limit. Bandwidth clogging
maybe a strategy used by slea y individuals or
may occur naturally. It aIIects network
perIormance by making system response
sluggish. Running close to the network
transmission capacity or exceeding it will
degrade response time.
Denial oI ervice (D ) attack D
attack is common in the web-centric model, i.e.
web browser and server. A website or IP address
can be overwhelmed by Ilooding re uests. or
example, ahoo suIIered a D attack one year
ago Irom coordinated hacker groups. It is an
inherited Ilaw in the domain name server (DN )
architecture. or a P2P network, D maybe
directed toward a key rende vous server or
primary relay servers.
Prying Eyes ometimes, data is
transmitted without encryption on the open
eptember, 2003, P2P Journal
network. A curious individual can use
network-sniIIing tools to capture and read those
data packets.
Encryption Cracking Encryption scheme is
not 00 immune to cracking. Given enough
time and suIIicient CPU cycle, most encryption
schemes can be broken.
Cancer Another way to cause problems is
to present misleading and wrong inIormation. In
the P2P network, content is not centrally
managed or stored on a single server. Anyone
can become a content provider and take
advantage oI this situation.
Backdoor Access Loopholes Because
P2P applications behave as both clients and
servers, it is possible to exploit those Iunctions
to create backdoor access to other people`s
system, including modiIying and deleting vital
system Iiles.
Man-In-The-Middle Attack P2P network
has no central server to coordinate identity
veriIication. Man-in-the-middle attacks maybe a
particularly prevalent means to disrupt
conIusion and corrupt trust.
Legality Issues Nowadays, inIormation has
intellectual property rights. There are gray areas
involving Iile sharing, i.e. redistributing music
and movie Iiles.
As P2P networks are oIten unmanaged, setting
up a uniIorm security policy is very diIIicult. The
boundary between intra-enterprise and
extra-enterprise P2P network is oIten Iussy and
diIIicult to monitor. No matter how well we
design and guard Internet, there will always be
loopholes to be exploited and ways to disrupt
service.
ome companies regard the pyramid (see
igure ) as their overall enterprise security policy
or standards.
uch an approach is unlikely to work Ior the
P2P network. In the P2P world, relationships are
transient and, connection is non-constant. It is
particularly diIIicult to monitor all activities and
to track inIormation Ilow. ame connection or
traIIic Ilow may not occur twice ever. And,
blocking certain ports may not deter P2P
communications. Many sophisticate P2P
applications have evolved to gain port-hopping
capabilities, meaning that they can use any
random ports to establish contact with outside
world. Another Iailed example is to use protocol
blocking, because many P2P applications can use
either TTP-tunneling or TCP-tunneling to
bypass Iirewalls.
8VEJJMG
1SRMXSVMRK
&ERH[MHXL
'SRXVSP
4VSXSGSP
%REP]WMW
4SVX &PSGOMRK ERH
7MXI &PEGOPMWXMRK
:EVMSYW *MVI[EPP
'SRXVSPW
%RXMZMVYW 7SPYXMSR
)QTPS]II 'SQTYXIV 9WI
%KVIIQIRXW ERH 4SPMGMIW
3ZIVEPP )RXIVTVMWI 0MEFMPMX]
%WWIWWQIRX ERH 3XLIV
4VIZIRXMSR 8IGLRMUYIW
Eigure 1. Security Pyramid
Rather than blocking or locking out P2P traIIic.
enterprises should take an active approach to
channel P2P computing in the positive direction.
And. authentication. authorization. and auditing
services should Iorm the basis Ior enterprise
security guidelines.
Security can be established at diIIerent levels.
such as at the network level. the application level.
or at the identity level. Next Iew sections will
explore those topics in detail. As P2P is the
ultimate distributed computing technology. in
term oI being loosely associated. using centralized
administration or blocking traIIic will meet
limited success. Instead. using a selI-regulated
'trust¨ mechanism or a good reputation
management system maybe better solutions Ior
the P2P network.
September. 2003. P2P Journal
9
Network Security and Trust Stack
Networking technology is the Ioundation Ior
all communications on the Internet. The most
prevailing networking standard Ior the
telecommunication industry is SS7 (Signaling
System Number 7) stack and protocol. (see Eigure
2) The SS7 separates data communication into 7
stratums Physical. Data. Network. Transport.
Session. Presentation. and Application.
Eigure 2. SS7 Stack
The 'physical¨. the 'data link¨. and the
'network¨ layers deal with low-level physical
attributes oI the network.
At the transport and packet level. Internet
Protocol version 6 (IPv6) is emerging as the next
generation data transmission standard. IPv6 oIIers
several advantages over IPv4. particularly in the
area oI security and perIormance. Eor example.
through IPsec. IPv6 oIIers support Ior PKI and
X.509 certiIicate services. Additionally. IPv6
oIIers a Ilow control mechanism and a simpliIied
header. making it easier to process and digest
inIormation packets. Some P2P SDKs even
consider IPv6 as a pre-requisite. Maiority oI P2P
application developers and users Iind the upper 4
layers are more interesting.
There are a variety oI transport protocols
available to guarantee the data integrity and
validity. Eor example. there are HTTPS (secure
hyper-text transIer protocol). SSL (secure socket
layer). TLS (transport layer security). etc. Bulk oI
which use encryption to gabble up data bits. There
are multitude oI diIIerent encryption algorithms
and key generation schemes. To name a Iew. there
are triple DES (abbreviated Irom Data Encryption
Standard). RSA (named aIter its inventors. Ron
Rivest. Adi Shamir and Leonard Adleman). RC4
(a stream cipher designed by Rivest). MD5
(stands Ior Message-Digest Algorithm. an
one-way encryption algorithm). SHA-1
(abbreviated Irom Secure Hash Algorithm 1).
random prime-number generator. DiIIey-Hellman
(named aIter WhitIield DiIIie and Martin
Hellman). CAST (named aIter inventors Carlisle
Adams and StaIIord Tavares). IDEA.
(abbreviated Irom International Data Encryption
Algorithm. a symmetric algorithm which PGP
uses in combination with RSA). etc.
There are two diIIerent approaches to ship
secure messages over the open-Internet. Eirst. a
message maybe encrypted as a stream oI bytes.
The second approach is to encrypt the whole
message as a single set. Consideration Ior
perIormance. ease oI implementation. validation
on the message. and content propagation should
be taken into accounts beIore deciding on using
which method or employing a hybrid system.
Establishing security at the session level
requires having some architecture planning
beIorehand. A session is setup between two
endpoints to keep track oI the state oI
communication. A session can deIine a
conversation context. Ior example. a discussion
topic about weather. It is recommended that a
session have a deIinite liIe span. which maybe
aIIected by the nature oI the protocol running. the
network reIresh rate. availability and cost oI other
system resources. and Iluctuation in the number oI
concurrent connections. etc. It is a measure to
saIeguard against identity theIt or backdoor
access.
September. 2003. P2P Journal
10
At the 'presentation¨ and the 'application¨
levels. having good security design are even more
obvious. User has certain tolerance level as to the
number and the Irequency Ior authentication and
re-authentication. such as log onto the system and
time-out due to inactivity. In a P2P network.
where nodes are organized in the parallel Iashion
and have transient relationship with respect to
each other. one must take care to design a system
that can eIIiciently transmit and propagate
identities without compromise security. A balance
between users` desire to minimize the amount oI
repetitive and unnecessary authentications with
suIIicient saIeguard against potential identity
Irauds and exploits. such as man in the middle
attack. identity theIt. traIIic sniIIing. is very
important. Whether to store and process
authentication tokens locally or on designated
third-party peers needs to be planned careIully in
accordance to security architecture. desired
perIormance target. and record-keeping needs.
BeIore messages are passed back and Iorth. a
user`s identity should already be established.
authenticated. and veriIied. A Iamiliar approach to
establish identity is using digitally signed
certiIicates. This brings us to the next topic
digital certiIicates.
Digital Certificates
Digital certiIicates can be used in coniunction
with PKI (Public Key InIrastructure) and X.509
certiIicates. There are diIIerent schools oI
thoughts on how to use. generate. and veriIy
digital certiIicates. A routine approach would be
creating a certiIicate authority (CA). a designate
and well-known body that regulates digital
certiIicate`s issuance and its validity.
There are many diIIerent ways to organize and
set up CAs. Eor example. one can setup a CA at
the global level. whereas a single authority is
responsible Ior all activities such as certiIicate
request service (CRS). generation oI private and
public keys. issuance oI certiIicate. tracking oI
certiIicates. updating certiIicate status. revoking
certiIicate. amend certiIicate guideline. resolving
certiIicate conIlicts. etc. When setting up CAs.
perIormance and relevance are also important
considerations. Clearly. this approach has
limitation. As a P2P network gets beyond certain
size. it will be overwhelming Ior a single entity to
do all those above tasks. Additionally. many
certiIicate holders have diIIerent interests and are
coming Irom diIIerent aspects oI liIe. The
certiIicate issued by a global CA will be too
general. and not specialized to Iocus on a
particular interest group. It means that it is too
coarse to reIlect the true value oI a certiIicate
holder. On the other hand. the Ilat structure oI a
single global CA makes it easy to write certiIicate
validation and monitoring Iunctions Irom the
developer`s perspective.
An alternative approach will be creating
diIIerent CAs Ior peer groups that are based on
similar interests. services. and contents. Each peer
group will have a primary CA who maybe also is
the group creator. When a new peer wishes to ioin
that group. the group creator/CA will receive a
CRS. It can be up to the group creator/CA or the
whole group in making the decision whether to
admit a new member. This approach shiIts CA
responsibilities (issuance. maintenance. and
validation) to the peer group leader and could
potentially be more manageable. Additionally. it
also avoids having a single-point-oI Iailure.
However. it does create a silo problem. meaning
how to exchange and validate digital certiIicates
issued by diIIerent CAs. particularly there are
multiple root certiIicates.
A third approach will have each-peer being its
own signing CA. The selI-signing approach
completely avoids the delegate situation oI
requiring a third party. This method eliminates
overhead and the request-wait situation. However.
very Iew people will ever want to invalidate or
revoke their own certiIicates. II selI-signed
certiIicates are Iorever good regardless oI owner`s
action. its credential carries very little value.
A Iorth approach is to get rid oI digital
certiIicates all together and to completely base on
the honor system. This approach may work Ior a
causal setting with inconsequential
inIormation/content. However. such an approach
will not meet stringent requirements associated
with the enterprise-computing environment. since
an administrator cannot set security policies or
September. 2003. P2P Journal
11
regulate the system. This is a blind trust situation.
Distributed Trust and Scoring
On JXTA`s website. there are discussions
about using Poblano`s model Ior distributed trust
and reputation scoring. (Poblano is a type oI spicy.
tropical pepper used in the cooking.) Poblano`s
model is designed Ior very loosely coupled.
ad-hoc P2P environment. Poblano's model
emphasizes trust and conIidence.
Trust is more than scrambling a document`s
bits and bytes. It`s also about taking risk. showing
bias toward certain action. data. people. or entities.
It may be build over-time by keeping track oI
general user conIidence in the entire P2P group.
Or. it may be based on words-oI-month Irom
search engine`s result and other peer`s
recommendations.
Poblano`s model measures conIidence in three
dimensions.
Peer ConIidence It ties a reputation score
to a peer`s ID and helps to determine
whether an entity is trustworthy or not.
Codat ConIidence This is used to link
relevance and popularity to a piece oI codat
(code ¹ data). It also produces keywords.
allowing search engine to index content.
Risk This is used to show a peer`s
reliability. perIormance. and accessibility
attributes.
The metrics values range Irom 1. 0. 1. 2. 3.
and 4. (1 means complete distrust. 0 means
ignore. 1 means minimal trust. 2 means average
trust. 3 means good trust. 4 means complete trust.)
Poblano`s model Iurther deIines trust as the
'sum¨ oI Peer ConIidence and Risk. It also
provides several mathematical equations Ior
calculating conIidence scores. Those values can
be propagated throughout the network. providing
basis Ior Iuture relationships.
Poblano`s model ties reputation to identity. It
uses group experience and knowledge to score a
user/peer`s credibility. Reputation is measured by
how well a user is reviewed by other peers.
Read On
In this article. we brieIly covered P2P security.
We talked about the network and trust stack and
encryption technologies. We also discussed
digital certiIicates and CAs. And. we presented
Poblano`s model. a distributed model Ior trust
management. Security and trust are double edge
swords. Without them. P2P will not be accepted
by enterprise computing. Yet. having them in
excess will drag down a P2P network`s
perIormance and make things too complicated.
P2P application designers should ask
themselves several questions. Ior example. which
encryption technology to use or not to use. The
answer may depend on the sensitivity oI data.
whether prying eyes will do harm. II the answer is
yes. then one must use encryption. On the other
hand. one must also understand that the process to
encrypt data may require more CPU cycles.
resources. and. could carry a perIormance penalty.
Additionally. trust and reputation management &
propogation are also important architecture issues.
I have gathered some addition interesting
URLs. HopeIully. they are useIul to you.
Some Interesting URLs:
http://databases.si.umich.edu/reputations/ - The
'Reputations Research Network¨ gives people
inIormation about others' past perIormance. It can
enhance an on-line interaction environment by:
1. Helping people decide who to trust;
2. Encouraging people to be more trustworthy;
3. Discouraging those who are not trustworthy Irom
participating.
http://crypto-id.ixta.org Crypto-based ID proiect Ior
JXTA. particularly emphasize on network layer
security.
http://platIorm.ixta.org/iava/api/net/ixta/membership
/package-summary.html - JXTA membership and
trust management.
http://iaas-membership.ixta.org/servlets/ProiectHom
e - JAAS implementation oI the JXTA Membership
Service.
http://di.ixta.org/ - Distributed indexing and query
service Ior JXTA.
http://www.ixta.org/docs/pki-security-Ior-ixta.pdI -
'PKI Security Ior JXTA Overlay Networks¨. a paper
September. 2003. P2P Journal
12
by JeIIery Altman. CTO. IAM Consulting. 1.
Eebruary. 2003
http://www.science.unitn.it/~tomasi/think/paper.html
- An academic website containing archives oI P2P
papers.
http://www.erights.org/ - 'E-Rights¨ is the home oI
Elib and Elanguage.
1. Elib is a pure-Java library. It provides security Ior
inter-process and distributed programming. Its
cryptographic capability protocol enables
mutually suspicious Java processes to cooperate
saIely. and its event-loop concurrency and
message pipelining enable high perIormance
deadlock Iree distributed pure-obiect computing.
2. The E Language can be used to express what
happens within an obiect. The E language
provides a convenient and Iamiliar notation Ior
the ELib computational model. so you can
program in one model rather than two. Under the
covers. this notation expands into Kernel-E. a
minimalist lambda-language much like Scheme
or Smalltalk.
http://www.openprivacy.org/ - "The Open Privacy
initiative¨ is an open source collection oI soItware
Irameworks. protocols and services providing a
cryptographically secure and distributed platIorm Ior
creating. maintaining. and selectively sharing user
proIile inIormation. This site talks about protect one's
identity and reputation management.
http://www.instantmessagingplanet.com - 'Instant
Messaging Planet¨ is a portal dedicated to the
discussing oI using instant messaging (IM) and
associated technologies to conduct business.
http://www.ixta.org/docs/trust.pdI - The original
paper on Poblano`s model Ior distributed trust
management. although we are still waiting to see a
solid implementation Ior JXTA.
http://www-106.ibm.com/developerworks/iava/librar
y/i-p2pcol.html - 'The practice oI peer-to-peer
computing: Trust and security in peer-to-peer
networks¨. a paper by Todd Sundsted. January 18.
2002
http://ntrg.cs.tcd.ie/undergrad/4ba2.02-03/p10.html -
P2P Security by Declan Murphy. Jarlath Kelly. Keith
Curley. John Vickery. Dan O`KeeII
Raymond Gao is the
editor-in-chieI Ior P2P
Journal. He Iounded
P2P Journal in early
2003. He has a proven
track record involving
enterprise-level and
distributed computing
proiects. He has
spoken widely and is
well published. He is
currently working Ior
Nokia. His other interests include music. oil
painting. travel. and writing. He can be reached at
raygao(comcast.net or (972) 530-4562.
1his is a tiger cub that I am holding.
September. 2003. P2P Journal
13
JXTA Remote Desktop
A JXTA Application`s Tutorial
Daniel Brookshier
turbogeek(cluck.com
Erustration is the mother oI invention. I make a living
developing JXTA soItware and since JXTA is everywhere.
so am I. Email. chat. and telephone are the primary ways
which I do business and provide support to Iellow
developers and especially users. Erustration comes Irom
being blind to the user`s desktop. Helping a remote user is
like to be blind and have no hands.
But what can you do? You can`t Iorce everyone to install
remote control soItware. You could write application
speciIic control; but. that is questionable and maybe a waste
oI time. On the hand. I can embed generic desktop control in
my own my application. Then. I can control the soItware
plus the entire desktop. i.e. change settings or read log Iiles.
the 'Remote Help Valhalla¨. Thus. the idea Ior JXTA
Remote desktop was born. This article explains how I built
the JXTA Remote Desktop.
Simple Requirements
There are iust two key tasks Ior our remote desktop. The
Iirst is the capturing oI the display on the locally controlled
machine. The second is translating keyboard and mouse I/O
Irom an image oI the captured screen and sending them to
the remote computer. or simply. the mapping oI I/O Irom the
controller machine to the controlled machine.
There is one more requirement that is very important. We
need to be able to control the desktop Irom anywhere. This
is not as easy as it Iirst seems because there are Iirewalls.
DHCP. and other issues that get in the way oI talking
directly to a remote PC. The solution is to use a P2P
technology like JXTA that passes through these problems.
In eIIect. JXTA is the enabling technology that lets two
computers to communicate in true P2P mode.
Instant 3XTA
What is JXTA? It is still new. So. let me give you the
obligatory one-minute tour. JXTA is a Peer-to-Peer (P2P)
protocol. It maybe implemented in several languages (Java
being the reIerence implementation). Unlike its Iile sharing
relatives (EreeNet. Kazza. Gnutella). JXTA is designed as a
general purpose P2P platIorm Ior your every day
applications.
Concerns Ior security and intellectual property has caused
Internet to evolve. making it somewhat anti-P2P. Most
computers do not have a public IP or a static address
because they are running DHCP. Some PCs`es addresses are
hidden by Network Address Translation (NAT) and/or
Iirewalls. Most personal computers are not visible until they
starting to hit web server asking Ior web pages.
Even iI you can communicate with a PC. Iiguring out the
right PC is a little tough especially iI it`s a laptop that gets
moved between home and work. JXTA has ways to Iind the
PC no matter where it is by using a virtual network that
relays network locations and routes between computers.
The JXTA P2P network is overlaid on the Internet and uses
a combination oI direct TCP/IP and Hyper Text TransIer
Protocol (HTTP) Ior communication. Computers work
together to route or relay messages to other members oI the
network. There are no behemoth web and application
servers. no hosting. and no huge allocations oI costly
bandwidth. Servers may be involved. but JXTA is meant to
be on the edge oI the network at home. work. and wireless.
The good news about JXTA is that most oI that hard work is
already done Ior you and hidden by JXTA APIs. We don`t
need to understand Iirewalls. http tunneling. relays. routing.
and a dozen other things. All we need to know are a Iew
parts JXTA APIs to connect the PC`s and to transIer
messages.
The Robot
Ready Ior surprise? Java class that we use to see and control
the desktop is fava.awt.Robot. The Robot class is a new
class Ior JDK 1.4. It was introduced primarily Ior running
automated testing applications. It can see the entire display
and control the mouse and the keyboard. It also allows us to
create a bitmap oI all or part oI the desktop at any time. (In
table one. I have listed the key methods oI Robot and what
they do.)
Designing A Remote Desktop
The mechanics oI the remote control are simple. There is a
little magic to convert the image into something suitable Ior
transmitting and mapping events to Robot equivalents
1
. To

1
Robot sends raw events to the desktop so the data is not
identical to Java events. Eor example. mouse buttons use
diIIerent constants and not associated with key modiIiers.
September. 2003. P2P Journal
14
keep things simple. rather than storing obiects and messages
in the pure XML Iormat as many other JXTA applications d.
our obiects are serialized (similar to RMI but without any
handshaking overhead).
The JXTA design is nearly as simple as what we have
looked at so Iar. It`s very similar to another tutorial
published here at P2Piournal.com in the July issue. I have
created a simple Iramework that wraps the JXTA
bidirectional pipe API. JxtaBiDiPipe.
JxtaBiDiPipe has two modes oI operation. The Iirst is as a
server that waits Ior incoming connections. AIter getting a
connection. the JxtaBiDiPipe creates input and output pipes
ready Ior use. Each client peer will get its own set oI
JxtaBiDiPipe Ior connection. This is very similar to the
Java.io.Socket or the sister API in JXTA called JxtaSocket.
which creates I/O streams. rather than message based pipes.
I won`t describe how my Iramework is designed. It isolates
a Iew things that you don`t need to worry about. II you are
interested. read the prior paper on JX1ASocket in the July.
2003 issue oI P2Piournal. I will cover how my helper
classes are used later in this article.
Starting A Remote Peer
To start a peer listening Ior connections. the user Iills in a
text box with a name it will be associated with. The user
then presses the wait button which causes the
WaitButtonActionPerformed() to be called. This method in
turn creates and starts the Server1hread class. The code in
the run() method oI Server1hread is only executed within a
thread because it might take a moment to start the pipe
listener and we want the GUI to respond quickly.
In Server1hread (see Listing 1). we create a Manager and
pass the targetName1extField into the addServer() method
to cause it to create a server pipe that can be contacted via
the same name. Under the covers. the name is actually
converted to a hash coded JXTA ID. The
serverConnectionListener created and passed into the
addServer() method is used to create a session when a client
connects.
Listing 1 Thread that starts the JxtaBiDiPipe via the
Manager class.
class ServerThread extends Thread{
public void run() {
try{
serverManager ÷ new Manager("remote
desktop");
serverConnectionListener ÷ new
ServerConnectionListener();

serverManager.addServer(targetNameTextEield.getText().s
erverConnectionListener);
setTitle("I am a server and I am waiting");
}catch(Exception e){
LOG.error("error starting this peer as a
server.".e);
}
}
}
Connecting To The Remote Desktop
Connecting to the remote peer is similar to the process
waiting Ior a connection. The same name must be supplied
in order Ior the client to Iind the server. The key diIIerence
is that this time the result is a session obiect. Also. using
thread is important because it can take a while beIore peer
connections are established. (See Listing 2)
Listing 2 Thread that connects to a JxtaBiDiPipe via
the Manager class.
class ConnectThread extends Thread{
public void run(){
try{
System.out.println("connecting to server");
clientManager ÷ new Manager("remote
desktop");
clientMessageListener ÷ new
ClientMsgListener();
clientSession ÷
clientManager.connectToServer(targetNameTextEield.getT
ext(). clientMessageListener. null);
transmitting ÷ true;
Recorder recorder ÷ new Recorder();
recorder.start();
}catch(Exception e){
e.printStackTrace();
}
}
}
Sending Data
To send data. a simple approach is converting obiects to a
byte array. by marshaling the data with a
ObfectOutputStream and then to a BvteArravOutputStream
(see listing 3). The resulting byte array is then sent via the
Session obiect created earlier. This is similar to RMI
without the overhead. An advantage oI this approach is that
there is no need to marshal the obiects to an XML document.
Since both ends oI conversion reside in the Java platIorm.
there is no reason to use XML.
Listing 3 Method to convert the current queue to a byte
array and transmit via JXTA.
public void sendDataToClient(ArrayList sendThis){
try{
ByteArrayOutputStream stream ÷ new
September. 2003. P2P Journal
15
ByteArrayOutputStream();
ObiectOutputStream out ÷ new
ObiectOutputStream(stream);
synchronized(clientGeneratedEvents){
out.writeObiect(sendThis);
out.Ilush();
clientGeneratedEvents.clear();
}
stream.Ilush();
serverSession.sendMessage(stream.toByteArray());
out.close();
stream.close();
}catch(Exception e){
LOG.error("Error sending message to server".e);
}
}// End oI method sendDataToClient()
Receiving Data
Listing 4 shows the ClientMsgListener implementation. The
close() method iust sets a Boolean to cause the Recorder
class`s thread to terminate the next time it wakes up. The
message() method converts the byte array to Java obiects
using an ObfectInputStream. It also calls the
processFromServer() method. The pipeMsgEvent() method
is not used in this application
2
. The ServerMsgListener class
is identical to ClientMsgListener except it calls the
processFromServer() method.
Listing 4 Implementation oI the MessageListener
interIace to capture messages targeted Ior the controller
peer.
public class ClientMsgListener implements
MessageListener{
public void close() {
LOG.error("pipe closed");
recording ÷ Ialse;// stop the recorder thread
}

public void message(byte data||) {

System.out.println("got a message Irom the server");

try{
ObiectInputStream in ÷ new
ObiectInputStream(new ByteArrayInputStream(data));
ArrayList commands ÷ (ArrayList)
in.readObiect();
in.close();
processEromServer(commands);
}catch(Exception e){
e.printStackTrace();
}

2
This method is called iI there is a message not a binary or a
close message.
}

public void pipeMsgEvent
(net.ixta.pipe.PipeMsgEvent pipeMsgEvent) {
}

}// end oI inner class MsgListener
The Robot class can capture any area oI any display
3
. The
process is as simple as calling:
BuIIeredImage createScreenCapture(Rectangle rectangle);
We do have a Iew hurdles. Eirst. we need to convert a
BufferedImage to something that eIIiciently transmits. A
BufferedImage converted to a byte array is too wasteIul.
Instead. we will convert it to a JPEG with compression.
Listing 7 is our compressor that also converts the
compressed JPEG to a byte array which is ready to be
transmitted.
There is still a problem with transmission size. Some
desktops are very large; even in compressed Iormat. it can
take a lot oI data. A simple idea is to display the remote
desktop in a scrollable window and to only ask Ior the area
currently displayed in the window on the local PC. This way
we can easily reduce the data to iust what we are
concentrating on. Because we need to scroll the window to
another part oI the desktop Irom time to time. we need to
re-sync the entire desktop at regular intervals. Ideally the
new capture would only send diIIerences between the
current screen and the previous one.
The Recorder thread class in listing 5 makes the request
Irom the controller. There is a counter to capture the entire
desktop or iust the scroll pane`s current view port rectangle.
Listing 5 Recorder thread used to regularly transmit
the current queue oI events and to request a screen
capture Ior the selected area oI the screen.
class Recorder extends Thread{

Recorder(){
}
Rectangle subArea ÷ null;//Test Rectangle
int totalReIreshCountdown ÷0;
public void run() {
long start ÷ System.currentTimeMillis();
while(true){
System.out.println("requesting a screen scrape");
iI (--totalReIreshCountdown ·÷ 0 ''
subArea÷÷null){
totalReIreshCountdown ÷ reIreshCountdown;

iI (reportedScreenSize ÷÷ null){
subArea÷ new Rectangle(0.0.0.0);
}else{
subArea÷new

3
Some computers can have multiple displays.
September. 2003. P2P Journal
16
Rectangle(reportedScreenSize);
}
clientGeneratedEvents.add(subArea);
}else{
JViewport view ÷
targetScrollPane.getViewport();
subArea ÷ view.getViewRect();
System.out.println("subArea ÷ "¹subArea);
clientGeneratedEvents.add(subArea);
}

ArrayList sendingList;
synchronized(clientGeneratedEvents){
sendingList ÷ clientGeneratedEvents;
clientGeneratedEvents ÷ new ArrayList();
}
sendDataToServer(sendingList);
try{
synchronized(this){
wait(reIreshRate);
}
}catch(Exception e){
e.printStackTrace();
}
}// end oI while
}// end oI run()
}// End oI class Recorder
Capturing the Screen
The screen capture is simple. but the encoding takes a little
more work. Listing 6 shows the capture() method that is
called when requested by the controller peer. The code
captures the requested rectangle or the entire desktop. either
when the rectangle indicates a request Ior the whole screen
or iI this is the Iirst request.
Listing 6 Captures all or part oI the remote desktop.
protected void capture(Rectangle rect){
iI (rect.equals(deIaultRect)'' screenSize ÷÷ null){
screenSize ÷
iava.awt.Toolkit.getDeIaultToolkit().getScreenSize();
rect ÷ new Rectangle(screenSize);
}
System.out.println("rec÷"¹rect);
BuIIeredImage image ÷
robot.createScreenCapture(rect);
try{
byte || compressed ÷
compressImage(image.videoCompressionRate/100.0I);
ArrayList list ÷ new ArrayList(1);
Snapshot snapShot ÷ new
Snapshot(rect.compressed.screenSize);
list.add(snapShot);
System.out.println("sending image to client");
sendDataToClient(list);
System.out.println("sent image");
}catch(Exception e){
e.printStackTrace();
}
}
Compressing the image is important. Raw images can be
many times larger than compressed images. Size is
important. especially when we may be connected to a
remote peer via a slow dialup or via a relay peer when there
is a Iirewall in the way. The compression used in listing 7 is
JPEG. Strength oI the compression is controlled by the
remote user (or the remote user via this application no
need to add a data interIace Ior this capability). The results
are stored in a byte array Ior transport.
Listing 7 Compresses the remote desktop.
public byte || compressImage(BuIIeredImage image. Iloat
compressionQuality) {
byte || compressed ÷null;
try {

// Eind a ipeg writer
ImageWriter writer ÷ null;
Iterator iter ÷
ImageIO.getImageWritersByEormatName("ipg");
iI (iter.hasNext()) {
writer ÷ (ImageWriter)iter.next();
}

ByteArrayOutputStream stream ÷ new
ByteArrayOutputStream();
// Prepare output Iile
ImageOutputStream ios ÷
ImageIO.createImageOutputStream(stream);
writer.setOutput(ios);

// Set the compression quality
ImageWriteParam iwparam ÷ new
MyImageWriteParam();

iwparam.setCompressionMode(ImageWriteParam.MODE_
EXPLICIT) ;

iwparam.setCompressionQuality(compressionQuality);

// Write the image
writer.write(null. new IIOImage(image. null. null).
iwparam);
ios.Ilush();
compressed ÷ stream.toByteArray();
stream.close();
writer.dispose();
ios.close();
} catch (IOException e) {
e.printStackTrace();
}
return compressed;
}
September. 2003. P2P Journal
17
Mice and Men
Robot. as Iar as events go. is a source oI events. not a
recorder. Robot cannot intercept mouse and keyboard
events. it can only generate them. So we can watch a
desktops image. but we can`t record events. But since we
can record events Irom a Java window. we can map events
to an image oI the desktop and send events to the real
desktop.
There are diIIerences. however. between the Robot events
and Java events. Their diIIerences can be attributed to that
Java events are an abstraction and not pure desktop events.
Eor example. there is no notion oI clicked` Ior mouse
buttons and no notion oI typed` Ior key events. There is also
not concept oI dragged`. That means although we could see
'typed¨. 'clicked¨ and 'drag¨ events. we should ignore
them because 'mouse move¨. 'button up¨. 'button down¨.
'key press¨. and 'key released¨ are all we could send to the
remote desktop.
There is also a diIIerence in Constants. The mouse buttons
use a diIIerent constant than supplied by the mouse events.
Listing 8 shows how we remap the values. This remap is
done on the remote desktop because it is easier to iust send
mouse events.
Listing 8 Method to process mouse events.
protected void processMouse(MouseEvent me){
// Move the mouse
robot.mouseMove(me.getX(). me.getY());
// Press its buttons
int buttonMask ÷ 0;
int buttons ÷ me.getButton();
iI ((buttons & MouseEvent.BUTTON1)>0){
buttonMask ÷ InputEvent.BUTTON1_MASK;
System.out.println("button one pressed");
}
iI ((buttons & MouseEvent.BUTTON2)>0){
buttonMask '÷ InputEvent.BUTTON2_MASK;
}
iI ((buttons & MouseEvent.BUTTON3)>0){
buttonMask '÷ InputEvent.BUTTON3_MASK;
}
iI (me.getID()÷÷MouseEvent.MOUSE_PRESSED){
robot.mousePress(buttonMask);
}else iI
(me.getID()÷÷MouseEvent.MOUSE_RELEASED){
robot.mouseRelease(buttonMask);
}
}
Keyboard Record
When we get a key event. we only worry abut the
getKevCode() oI KevEvent because this is the equivalent oI
the key pressed or released methods in robot.
We use two classes RkevReleased and RkevPressed. to send
the events rather than a KevEvent. This reduces the size a
little to iust the key we need.
Things To Do
JXTA Remote Desktop is an Open Source proiect hosted at
http://ixta-remote-desktop.dev.iava.net/.This code oI this
article is iust the Iirst version. There are a Iew things
missing:
Screen captures should only send diIIerences.
EoolprooI JXTA conIiguration.
Multiple viewers oI a controled desktop.
Improved event handling.
Instant messaging chat
Record a session and play it back.
Security to prevent unauthorized access.
OI course. it is open sourced Ior a reason. Incomplete code
is a scratch that you need to itch. II you are Irustrated like
me you are itching to make JRD your ultimate Java
accessory. I`m sure you have a Iew ideas and are willing to
help whittle down the Iirst list oI enhancements. SoItware
like this makes us all look good.
Daniel Brookshier. the
author oI book.
"JXTA: Java P2P
Programming."
Daniel is a Senior Java
consultant. author. and
speaker with 20 years
oI experience. Daniel's
knowledge oI soItware
development covers many industries. He is an
international consultant with assignments around
the world. Daniel is the Iounder oI
Talk-Java/Drink-Java user groups in Texas and is
currently Iorming a new user group Ior JXTA P2P
developers.
He can be reached at turbogeek(cluck.com
September. 2003. P2P Journal
18
Remote
View
Remote
Desktop
Eigure 1 - JRD`s Graphical Representation
Robot method Purpose
MouseMove Changes the X/Y location oI the mouse in absolute desktop coordinates.
MousePress Generates a desktop event Ior a pressed mouse button(s)
mouseRelease Generates a desktop event Ior a released mouse button(s)
keyPress Generates a desktop event Ior a key press
keyRelease Generates a desktop event Ior a key release
createScreenCapture Converts a speciIied portion oI the desktop display to a buIIered image.
Table 1 Key Robot methods
Dear Iriend:
The Peer-to-Peer Journal (P2PJ) is a bi-monthly iournal that opens a Iorum to individuals and hi-
tech Iirms who/which are interested in applying, developing, educating, and advertising in the
Iields oI Peer-to-Peer (P2P) and parallel computing. P2P Journal intends to be the gathering
place Ior people interested in reading and writing articles or discussing and chatting about P2P,
instant messaging (IM), collaborative computing, Iile sharing & distribution tools and protocols,
and parallel computing topics, such as grid and cluster. Experts or people who are directly
engaged in those the Iields could contribute articles in P2PJ.
The Editor-in-chieI is now inviting you or your Iriends to submit papers or letters Ior publication
at P2PJ. Articles, whitepapers, product reviews, discussions, and letters or short communications
to iournal are accepted. For writer's guideline, see
http://p2piournal.com/main/p2pwritersguideline.pdI
Once an article is accepted Ior publication, P2P Journal retains its copyrights, although
contributors may get a written permission Irom P2PJ Ior quotation or reuse his/her articles Ior
non-proIit purpose.
P2PJ shall become a medium helping connect people and entities and disperse useIul
inIormation. We believe that through building a gathering place where people can exchange
ideas and inIormation, everyone will beneIit Irom it. In the spirit oI sharing and Ireely
exchanging ideas, P2PJ has an online chat room that allows instant communication between
online visitors.
P2PJ encourages every contributor to attach his/her passport photo to the article as well as a
short bio. That way it can increase the author's visibility. We may also give some valuable giIt to
contributors Ior the recognition Ior his/her contribution to P2P computing Iields.
Best regards,
Raymond F. Gao
Editor-in-ChieI, P2P Journal
N
N
o
o
v
v
e
e
m
m
b
b
e
e
r
r
,
,
2
2
0
0
0
0
3
3
Contents for November, 2003
An Extendible Open Source P2P Simulator
by am Joseph
This paper talks about P2P simulators and desirable Ieatures. It also presents
NeuroGrid, an extendible open source P2P simulator, and outline a number oI
ongoing proiects that are either using it or extending Irom that model.
Probabilistic Knowledge Discovery and Management for
P2P Networks
by Dimitrios Tsoumakos & Nick Roussopoulos
This paper describes the Adaptive Probabilistic earch method (AP ) Ior search in
unstructured P2P networks. AP utili es Ieedback Irom previous searches to
probabilistically guide Iuture ones.
Editor's Note
by Raymond Gao
Call for Paper
Use P2PJ's message board Ior all discussion related to this issue.
Cover Image: Who is the hunter
This picture was taken by Raymond Gao at Lake Balaton, ungary, May
3, 2002 ( i e - x 0 pixels)
Editor-in-ChieI: Raymond Gao, raygao(comcast.net
P2P imulation Editor: am Joseph, sam(neurogrid.com or sam(mtl.t.-u-tokyo.ac.ip
Contributing Editor: Dimitrios Tsoumakos, dtsouma(cs.umd.edu
JXTA Track Editor: Daniel Brookshier, turbogeek(cluck.com
Website Assistant: Jerry Giant, iariarbinkx(yeah.net
P2P Journal is currently accepting articles Ior January, 200 Issue
Copyright 2003: Unless with explicit written permission Irom P2P Journal, no part oI this iournal
may be recycled or reproduced in whole or parts.
1
15
21
22
P2P Journal, November, 2003
An Extendible Open Source P2P Simulator
Dr. am Joseph
trategic oItware Division, University oI Tokyo, Japan
sam(neurogrid.com sam(mtl.t.-u-tokyo.ac.ip
Abstract
A large number of peer-to-peer (p2p) svstems
have been developed in recent vears. Manv
of these new approaches to p2p networks
have been developed in parallel with a
simulator of one sort or another. Other
authors have alreadv started to call for
standardization in the area of p2p simulation
(Schlosser et al.. 2002). and this paper
supports that call. It also goes further to
suggest that an extendible open source
simulator is required. 1his paper also tries
to summarize some of the desirable features
of a p2p simulator bv looking at the different
existing simulators. We then present the
NeuroGrid simulator. an extendible open
source p2p simulator. and outline a number
of ongoing profects that have been
implemented bv extending from this
architectural base.
1: Introduction
A simulation is an attempt to model a
system in order to study it scientiIically (Law
& Kelton, 2000). II the relationships in the
model are simple enough an analytical
solution may be derived by mathematical
methods. owever the complexity oI real
world systems oIten prevents this, and thus a
numerical model or simulation is required in
order to estimate the true characteristics oI
the systems.
Peer-to-Peer (P2P) systems are
characteri ed by many oI these annoying real
liIe complexities, such as a high turnover oI
peers, download & connection Iailures, large
numbers oI stochastically behaving peers etc.
Analytical approaches are being applied to
P2P systems, but they oIten require
simpliIying assumptions that break down
under real world conditions. In addition the
intention oI many P2P systems is to scale to
large numbers oI peers and, testing that
scalability in the actual system may be
impractical. As a result P2P simulation
studies have been growing in number. Just
how relevant these simulation studies are to
the deployment oI real P2P systems is open
to question but it is an important question
that always needs to be asked oI simulation
studies.
The nature oI a simulation is to make
some assumptions and abstractions about the
system being modeled. II this were not the
case one might as well build the real system
Ior testing one`s theories. The problem is
which assumptions or abstractions to make,
since without a complete understanding oI
the system in question, anything that is leIt
out could turn out to be a central Iactor that
underpins the behaviour oI the real system.
andling this problem requires close
attention to simulation methodology. All too
oIten simulation studies involve building a
model and using the results oI a single run to
obtain the answer . (Law & Kelton, 2000)
In order Ior a simulation to be used to support
valid and credible conclusions, the diIIerent
assumptions taken must be careIully
assessed attention paid to the probability
distributions oI starting parameters, and the
results subiect to the appropriate statistical
analysis.
The study oI P2P systems is a new and
developing Iield, and as a consequence some
P2P Journal, November, 2003
2
oI the simulation studies conducted so Iar
leave something to be desired in terms oI
rigor. owever the situation is changing as
P2P practioners become aware oI the large
body oI existing work on simulation in
related Iields such as network
communications, and on simulation in
general. The author hopes that this review oI
existing simulators, and the analysis oI P2P
simulation needs in this paper will help
promote increasing levels oI standardi ation
and validity in P2P simulation.
The rest oI the paper is organi ed as
Iollows: In section 2 we analy e P2P
simulation requirements, while section 3
reviews some oI the existing simulators.
ection presents the NeuroGrid simulation
architecture, one oI the Iirst extensible open
source simulators, and section describes the
results oI two diIIerent extensions to that
Iramework. In section we summari e the
papers conclusions and discuss their
implications
2: Simulation Requirements
ome oI the various considerations that
need to be taken into account as regards P2P
simulators are given below:
A. tarting parameter distributions
B. Content model
C. Results analysis
D. Ability to seriali e network state
E. isuali ation, unit-testing .
2. Parameter Distributions
The results produced by most simulators
will be strongly aIIected by their starting
parameter distributions. peciIic to P2P
simulations are things like the starting
topology, content & query distributions and
churn rates. For example, possible network
topologies include ring, random, power-law,
Poisson, exponential, and arbitrarily speciIied
degree networks (Newman et al, 200 ) and
others such as those generated by the
Waxman method (Medina et al, 2000).
The Waxman method is an approach Ior
generating a random graph where links are
added to a pair oI nodes with a probability
based on a distance measure. We mention
the Waxman method in here because it is the
basis Ior the Transit tub method used in
several oI the simulators covered in the next
section. Creating a Transit tub topology
involves giving each node in the original
network a number oI sub-networks generated
by the Waxman method, and then adding a
little additional back-door connectivity.
The Transit tub method is popular because
it is thought to be a good approximation oI
real-world network structures, although there
has been some criticism oI this approach
( arris, J., personal communication).
The choice oI a starting topology depends
on whether the intention is to replicate the
observed topology oI a network such as
Gnutella, or to examine a scheme that would
achieve a diIIerent topological end state. The
term starting topology implies that the
simulation starts once the topology has been
created and that the topology is Iixed Ior the
duration oI the simulation, although the
topology generation may also be part oI a
dynamic P2P simulation. tudies oI real
world P2P networks can provide starting
distributions, although there might be
concern that a topology so produced was
merely reIlecting a number oI the statistical
properties oI the network studied and thus
miss out on idiosyncrasies speciIic to the
dynamic development oI the network in
question.
This brings us to the issue oI churn, or the
dynamic properties oI P2P networks such as
a high turnover oI peers, communication
Iailures and other Iactors with cause a P2P
topology to be in a constant state oI Ilux. II
this dynamism is to be included in the
simulation the churn itselI must be generated
Irom a number oI distributions that determine
the relative likelihoods oI peer Iailure, uptime
P2P Journal, November, 2003
3
and so Iorth. The approach taken by
chlosser et al (2002) oI attempting to
determine as many oI these distributions
Irom observations oI real-world P2P
networks seems the method most likely to
avoid discord between simulation and reality.
owever in some cases statistical data on
certain aspects oI a P2P system may not be
available, such as detailed data on query
distributions in systems with anonymi ing
properties. In this case it is necessary to
approximate, Ior example, with a distribution
derived Irom studies oI non-P2P systems
with related characteristics. Although
naturally this must go hand in hand with the
reali ation that the simulation results will
only be valid to the extent that these
estimated distributions are eventually
conIirmed in the real P2P system.
2.2: Content models
Content also needs to be distributed
through a P2P system in order to perIorm a
simulation. The issues oI the previous section
apply to content distributions as well, but
there is also the matter oI how to model
content within the system, given that some
content models may not encapsulate all the
ways in which users relate to the available
content. There are a number oI orthogonal
issues here:
. Representational complexity
2. ocabulary
3. Fundamental concepts
. Dishonesty
The representational complexity oI the
content model determines whether content is
represented in terms oI hashes, categories,
keywords, or more complex Iorms like
predicate triples. For example, this document
is represented by hash X, or this document is
in category X and no other, or this document
is related to whales and dolphins, or this
document deIines whales and has
illustrations oI dolphins . There is also the
issue oI vocabulary, or whether users map
Iundamental concepts onto the same terms,
e.g. I say whale and you say kuiira , but
we both mean marine mammal. Further there
is the question oI agreement about
Iundamental concepts you say this marine
mammal is Iood and I say it is sentient. This
issue oI shared Iundamental concepts is
important as it determines whether we can we
describe things in a content-centric Iashion,
or must we use a user-centric model. Finally
there is dishonesty, in which case users
misrepresent their belieIs about content, e.g.
you say this is a revolutionary product and
I say this is unsolicited iunk. In addition
each oI the above issues are subiect to
dynamic evolutionary processes where users
change opinions and strategies over time. All
these various Iactors need to be considered in
order to select the appropriate content model
Ior a simulation. For more on content
modeling in P2P networks see Joseph &
oshiai (2003).
2.3: Results Analysis
Law & Kelton (2000) lament the tendency
Ior simulations to be run once to obtain an
answer . Given that various probability
distributions have been sampled in order to
select the simulations input parameters, it
Iollows that the results oI a single run oI the
simulation may not reIlect the true nature oI
the underlying model.
The solution in the Iirst instance is to run
multiple simulations starting with diIIerent
selections Irom the same input probability
distributions and present results indicating
the variation in output. More rigorous
approaches advocated by Law & Kelton
(2000) include repeating assessment oI
conIidence intervals, aIter sets oI additional
simulations, until the speciIied precision is
acquired. Actually obtaining an appropriate
result Irom an individual simulation run is
not without diIIiculty as it oIten relies on
P2P Journal, November, 2003
waiting Ior a system to achieve a steady state.
Assessing steady state achievement is almost
as much art as science and in addition, it
could be argued that P2P networks exhibiting
high-churn could maintain themselves Iar
Irom any equilibrium position.
2. : Network eriali ation
A more immediate practical issue that
arises Ior P2P simulations is one oI
seriali ing network state. Given that a
topology has been generated Irom
appropriate input distributions it makes sense
that the simulator should support the
seriali ation oI that inIormation to long-term
storage. Being able to back up the state oI a
simulated network allows expensive start-up
operations to be avoided each time the
simulation is run, and can also allow the
simulation to be stopped and re-started to
check whether equilibrium states have been
reached. Ideally a standardi ed XML based
approach or Network Markup Language
(NML) (Joseph, submitted) would be
employed. owever, useIul as the ability to
store and retrieve network state is, one must
be careIul to reali e that a particular starting
state is only a single estimate oI the input
distributions, and so cannot be used to
generate multiple results that would then
support statistical analysis oI the models
true behaviour.
2. : isuali ation, Unit-testing
The ability to seriali e the state oI a
network is also useIul in that it can help
support visuali ation oI the network by third
party soItware. isuali ation can be
important Ior understanding the nature oI the
model, as well as helping debug aspects oI
the simulation itselI. Given that the
simulation is a programmatic reali ation oI a
particular model, it is naturally important to
ensure that it is a valid representation.
While visuali ation can help achieve this
goal, it is the author`s Iirm belieI that the
application oI a rigorous unit-testing
Iramework (Zhu et al., ) is the best way
to ensure that the simulation is doing what
the programmer intends oI it. Particularly in
the case oI an extensible simulator where
additional Iunctionality is being added, it
makes particular sense to employ a unit-
testing Iramework that allows bulk checking
oI the system Iunctionality to be automated.
3: Existing Simulators
3. : ueryCycle imulator
chlosser et al. (2002) present the
ueryCycle simulator in which content
distribution is based on the concept that Iiles
belong to one oI a number oI categories, and
that each Iile is uniquely deIined within a
category by its popularity, which in this
context, means the extent to which it is
shared within the network and queried Ior.
This scheme may make sense Ior a Gnutella-
like network, although it does not allow room
Ior Iiles to Iall into more than one category,
or Ior users to disagree about the category oI
a Iile.
The ueryCycle imulator itselI operates
in cycles within which each peer makes a
query and then selects an appropriate
download. The main imulation class
maintains a single message queue, and any
message that is generated is passed into this
queue and then handled on a FIFO basis.
The ueryCycle parameters are split into
Content parameters speciIic to the content
model mentioned above, Peer Behaviour and
Network parameters. Peer Behaviour
parameters include, uptime, query Irequency
& type and download selections. Network
parameters include topology and available
bandwidth. The authors recogni e how
realistic parameter distributions aIIect
simulation results, and so as many oI these
parameters as possible are derived Irom real
P2P Journal, November, 2003
data taken Irom studies oI the Gnutella
network ( aroiu et al, 2002).
3.2: Narses imulator
Narses is a Ilow-based network simulator,
(Baker & Giuli, 2002) designed to avoid the
overhead oI packet level simulators like the
ns simulator. Baker & Giuli cite the work oI
Ahn & Dan ig ( ) to indicate that the si e
oI the event queue in packet level simulators
can have a serious impact on the perIormance
oI the simulator. Narses uses a Ilow-based
simulation to avoid simulation oI lower level
details and oIIers a range oI models that trade
between Iast runtimes and accuracy. Narses
is thereIore somewhere between packet level
simulators and analytical models. Narses`
Ilow-based model assumes no bottleneck
bandwidths in the core oI the network so
there is no need to simulate intermediate
routers. Bandwidth is allocated based on a
Iunction oI the available bandwidth and the
number oI ongoing Ilows. Experiments show
a -Iold speedup over the ns simulator
(URL ), while using only 2 ° oI the
memory while maintaining accuracy to
within °.
3.3: imP
2
imulator
The imP
2
simulator (Kant & Iyer, 2003)
is designed to provide support and additional
depth to an analysis oI ad-hoc p2p networks.
The analysis is based on a non-uniIorm
random graph model (Kant, 2003), and is
limited to studying basic properties such as
reachability and nodal degree. imulation is
employed to assess more detailed
perIormance characteristics such as queuing
delays and message loss. The simulator can
take any sort oI graph input, such as a set oI
network instances created using the same
network construction approach as the
analytical model.
Kant & Iyer`s P2P networks are
considered in terms oI a three-tier model:
. Distinguished nodes: always on, high
bandwidth
2. Undistinguished nodes: oIten on, lots oI
content
3. Transient nodes: present occasionally,
little content
imP
2
ignores transient nodes and other
dynamic aspects oI the network Ior the
purpose oI tractability. The simulator
supports investigation oI the network
properties through a process oI constrained
connectivity where the diIIerent network
instances are selected such that their
connectivity patterns Iall into a narrow band
around the average levels.
The imulator itselI is written in C/C
and uses im (Bae ner et al., 0) as a
simulation engine, a library oI routines Ior
implementing discrete event simulations.
3. : BI ON imulator
BI ON is the Biology-Inspired techniques
Ior elI Organi ation in Dynamic Networks
proiect, which includes a simulator. BI ON
proposes two diIIerent architectures a
simulation architecture built on an existing
packet-level simulator, GloMo im (Zheng et
al., ) and a custom designed overlay
network simulator. The idea is to provide a
conIiguration service that allows diIIerent
components oI the simulation to be added
and removed. The BI ON proiect has
developed Irom work on the Anthill proiect
(Babaoglu et al., 2002), a P2P simulator
designed with social insect modeling in mind.
Anthill was built on top oI JXTA and uses
the same implementation Ior both simulation
and run-time environments. BI ON is still in
early development and so details are
somewhat scarce.
P2P Journal, November, 2003
3. : 3L imulator
3L (Ting & Deters, 2003) is a time-
stepped simulator that uses a central step-
clock. The system is separated into three
levels:
. Network model
2. Protocol model
3. User model
The network model is described in terms
oI distance values between the nodes using a
two dimensional matrix, while the protocol
model represents the particular p2p protocol
being investigated. The user model simulates
input Irom users.
Montresor et al. (2003) observed that 3L
is not particularly eIIicient as regards
memory usage, and thus simulations are
limited to rather small networks. owever,
3L makes use oI a Graph Description
Language (GDL), notably not an XML
Iormat, but a representation speciIic to the
Ai ee proiect (URL2). Ai ee is an
application that supports graph visuali ation
oI networks in GDL Iormat, and through this
3L supports sophisticated network
visuali ation.
3. : Packet-level Peer-to-Peer (PLP2P)
imulator
Many P2P simulations do not simulate the
underlying network layer, because simulating
the packet level details takes up resources
that could be spent on scaling up higher
levels oI the simulation. The PLP2P
simulator ( e et al., 2003) provides a
Iramework that can be used in coniunction
with diIIerent packet-level network
simulators. In order to run on top oI
simulators that do not support the standard
socket interIace, appropriate wrappers are
created, such as Ior the ns simulator (URL ).
In addition there is a Null ocket interIace
included that allows the packet-level details
to be ignored.
The authors oI the PLP2P simulator assert
that Iailure to consider low-level details can
lead to inaccuracies in the simulation.
Further, they suggest that the intermediate
Ilow model approach may be insuIIicient to
handle this problem.
PLP2P consists oI three levels represented
by a PeerAgent, a PeerApp and a ocket
Adaptation layer. The ocket Adaptation
layer provides core system socket operations
such as bind, listen, connect, recv and poll
while the PeerApp incorporates the user
interIace e.g. APIs used by application users
such as foin, leave, idle, share and search.
The PeerApp also maintains peer
relationships and receives upcalls Irom the
PeerAgent such as quervhit. The PeerAgent
handles message processing and routing,
while a separate ActivityController generates
user events.
The PeerAgent and PeerApp classes can
then be extended to support diIIerent P2P
systems, e.g. by creating GnutellaAgent and
GnutellaPeer and over-riding the appropriate
operations. Experiments based on Transit
tub backbone networks were perIormed to
examine the distribution oI access bandwidth
or the link delay on the backbone (peer
proximity). The results showed substantial
(order oI magnitude) eIIects on Gnutella
system throughput values, when compared
with an analytic model that ignores packet
level details. The criticism oI low-level
simulators is that they do not scale so well,
but PLP2P scales to larger networks by
running simulations on parallel machines.
3. : Proiect imulators
arious P2P proiects have produced their
own dedicated simulators. For example
Freenet (Clarke et al., 2000) has both Aurora,
in C , and erapis in Java which supports
the evaluation oI diIIerent caching
algorithms. Limewire has its own simulator
P2P Journal, November, 2003
Ior the Gnutella network, while Chord
( toica et al., 200 ) and Pastry (Druschel &
Rowstron, 200 ) also have their own
simulators. Ocean tore/Tapestry (Zhao et al.,
200 ) is an exception in that some supporting
simulations have been run on the ns simulator.
4: NeuroGrid Simulator Architecture
The NeuroGrid simulator was originally
designed to support comparative simulations
between the Freenet, Gnutella and NeuroGrid
systems (Joseph, 2002 Joseph, 2003).
Unlike many other simulators that were
designed Ior a speciIic P2P system, the
NeuroGrid simulator was explicitly created
with extensibility in mind.
. : imulator Classes
The imulator makes use oI a number oI
abstract classes that are intended to be
generic across diIIerent P2P implementations.
For example, the abstract Network class
provides deIault methods Ior node addition
and speciIic topology generation over the
existing nodes. Implementations oI other
P2P systems then extend this class,
implementing variations on the deIault
methods where necessary.
Each system may also require other
associated abstract classes to also be over-
ridden, such as Node, Message andler or
Comparator - depending on the type oI
system being modeled and how it is being
implemented. DeIault topology options
include random, ring and power-law, and
there are currently a range oI P2P systems to
choose Irom including Gnutella, NeuroGrid,
Freenet and Pastry. arious other abstract
classes span these diIIerent systems: Network
contains Nodes (think peers), and each Node
may contain Documents, which in turn may
possess Keywords. These Documents do not
necessarily represent text Iiles and the
Keywords do not necessarily represent words.
This varies across diIIerent simulations, with
Documents being extended to emails, Iiles,
etc. and Keywords being things like hash
keys in the Freenet simulation and IP
addresses in a DN simulation.
A complete list oI the abstract classes
provided by the NeuroGrid simulator is as
Iollows:
. Keyword
2. Document
3. Message
. Node
. Network
. Message andler
ome oI these abstract classes include
Iunctional components others represent
entities within the network, while some
include both Iunctional and representational
components. In all cases the use oI abstract
classes rather than interIaces allows deIault
behaviours and data structures to be in place
to get developers up and running as quickly
as possible.
All obiects have unique IDs that are
coordinated across instances. The abstract
classes each maintain a static global ID Ior
example, the Keyword class includes a static
variable representing a global keyword ID.
Each time a new obiect is created the static
ID value is incremented, and an id oI that
value is associated with the new obiect in
static hashtables within each class.
The use oI static member variables allows
the simulation to co-ordinate obiect IDs, and
also provides easy global programmatic
access to the range oI available obiects.
While a real system would not have local
access to variables in this Iashion, the
structure is useIul in a simulation where we
require global activities such as creating
certain kinds oI content distributions.
owever the developer must then be careIul
not to abuse the ability to access this
inIormation and thus add operations that
would be impossible in a distributed
environment. An alternative approach would
P2P Journal, November, 2003
be to make more extensive use oI the Java
hashcode() Iunction, to avoid the need Ior
separate tracking oI obiect IDs. There is a
trade-oII here between convenience Ior
developers and encourage good obiect-
oriented practice, which discourages the use
oI globally accessible variables.
.2: upporting DiIIerent Protocols
In order to create a simulation oI, say, a
Gnutella network, various abstract classes are
extended to make concrete classes like those
shown in Iigure . The Keyword abstract
class co-ordinates the keyword id and
keyword relationships in hashtables, while
Iarming out the exact nature oI the Keyword
representation to the impleKeyword class.
The impleKeyword class can be used Ior
various p2p simulations, but Iunctionality
speciIic to Gnutella is placed in classes like
GnutellaMessage andler and GnutellaNode,
which extends the abstract Node class.
The abstract Message class contains a
number oI variables generic across messages,
speciIically a time to live (TTL) counter and
three Node reIerences, regarding where the
message is now, where is was immediately
previously and where it originated. A Iurther
abstract class, ContentMessage, extends the
abstract Message class in order to provide
support Ior the Message to carry inIormation
about a Document and associated Keywords.
impleContentMessage then implements
special constructors that can be used to
support message cloning Ior Ilooding
operations.
The abstract Node class contains more
data structures: a map oI connections to other
nodes, Multi ashtables (that support
mappings oI multiple values to the same key)
that map keywords and document ids to
speciIic content. It also contains a
knowledge base that can store inIormation
about other nodes, a table oI seen messages, a
message inbox and most importantly a
Message andler. The Iunctionality oI the
abstract Node class reIlects the origins oI this
soItware in supporting the simulation oI
Gnutella-like networks. Thus the deIault
node is assumed to have some contents, the
ability to screen out previously seen
messages and so Iorth.
Fig. 1: Some of the base Simulator abstract classes
and their extensions to support Gnutella simulation.
Originally the message-handling
operations were abstract methods in the Node
class, but they were re-Iactored into classes
that implement the Message andler interIace.
This means that classes that extend the Node
class, like GnutellaNode, do little more than
provide representational implementations,
and the Iunctionality oI the Iinal node is
achieved by a combination oI the abstract
Node class and the type oI Message andler it
is paired with.
Further reIactoring is anticipated in order
to separate out orthogonal aspects oI the node
class, e.g. the contents handling, the
Keyword
SimpleKeyword
Keyword lD
Hashtable
Document
SimpleDocument
DoclD
Hashtable
Message
Message lD
Hashtable
Node
GnutellaNode
Node lD
Hashtable
ContentMessage
SimpleContentMessage
P2P Journal, November, 2003
connection handling, and the knowledge base
could all be separated out to some extent
allowing a even more Ilexible mix and match
oI diIIerent Iunctionalities.
o in order to create nodes that will
display Gnutella-like Iunctionality the
GnutellaNode class extends the abstract Node
class, adds some representational
implementation and selects a
GnutellaMessage andler. The important
Message andler interIace methods are as
Iollows:
puo||c ooo|ean hand|eVessage(Vessage ressage,
Node nodeI
|h|oWs Excep||on,
puo||c ooo|ean |njec|Vessage(Vessage ressage,
Node nodeI
|h|oWs Excep||on,
Code. 1: MessageHandler interface
The handleMessage method is intended to
handle an arbitrary incoming message, while
the iniectMessage method is intended Ior
messages that are being initiated - in a real
system this would presumably correspond to
a message being generated in response to
some action oI a user. Thus the
iniectMessage method will usually iust do
preparatory work on the local node - and will
subsequently be handled at the request oI the
Action Event Iramework, which we will
describe in more detail shortly. First, let us
look at some oI the GnutellaMessage andler
implementation:
puo||c ooo|ean hand|eVessage(Con|en|Vessage
ressage, Node nodeI
|h|oWs Excep||on
{
|| 1. bpda|e s|a|s |e ressage ||ansle|
Ne|Wo||.o_ressage_||ansle|s÷÷,
|| 2. Chec| Whe|he| ressage has oeen seen
|l (seenVessage(ressage, nodeI == ||ue
{ |e|u|n la|se, }
|| 3. bpda|e node ac||v||y s|a|s
node.se|Ac||ve(I,
|| 4. |erove ressage l|or nodes |noox
node.|eroveF|orlnoox(ressageI,
|| 5. chec| lo| a |oca| ra|ch
chec|Loca|Va|ch(ressage, nodeI,
|| b. chec| ressage TTL
|l (chec|VessageTTL(ressage, nodeI == la|seI
{ |e|u|n la|se, }
|| 1. add ressage |o a|| connec|ed nodes
|| (excep| |he one We |ece|ved l|or I
|e|u|n lo|Wa|dVessage(ressage, nodeI,
}
Code. 2: GnutellaMessageHandler implementation
As we can see Irom the above code, it is
the handleMessage method that implements
the Gnutella-style routing and thus changing
the operation oI the network is as simple as
editing or over-riding this method and
creating nodes with the relevant
Message andlers. Incoming calls to a
Node's handleMessage method are Iorwarded
to the Message andlers` handleMessage
method, which then calls various methods
speciIic to the Message andler in question,
as well as calling operations on the node that
this Message andler is associated with.
P2P Journal, November, 2003
0
.2: Action Event Framework
The remaining issue is how to
consecutively call the Node's handleMessage
methods in order to simulate messages
moving through the network, potentially in
parallel. Early versions oI the simulator used
a table oI TTL values to message obiects to
track messages through the network the
Network class's searchNetwork method
including a loop that worked Irom the highest
TTL messages to the lowest, calling the
handleMessage method oI the node the
message was Iound in. This rather crude
approach was suIIicient Ior Gnutella, Freenet
and NeuroGrid simulations where one could
rely on message TTLs continually decreasing.
In order to support a wider range oI p2p
networks, as well as allow Ior variable
message transmission times, the simulator
was switched to a more Ilexible Action Event
Iramework.
The Action Event Iramework makes use
oI an Action interIace, implemented by
classes like the andleMessageAction. The
Action interIace consists oI a single execute
method. The andleMessageAction contains
a single Message and implements the execute
method to call the handleMessage method oI
the node in which the Message is currently
located. This then leads to the operation oI
the appropriate Message andler. The main
diIIerence Irom the original TTL table is that
all Actions are placed in a table (in the
EventNetwork class), which associates each
Action with a global timestamp. Multiple
Actions can be associated with a given
timestamp in an arbitrary sequence. The
abstract Node class's addMessageToInbox
method then takes care that any incoming
messages are added to the event map at an
appropriate point in the Iuture as new
andleMessageActions.
Fig. 2: Event table showing Actions associated with
different timesteps (see text for details)
Thus adding a andleMessageAction at
timestamp ero, the process oI looping
through timestamps and executing the
associated actions causes the spread oI
messages through the network. Each action
potentially spawning actions that will be
scheduled to take place in the Iuture. Placing
actions Iurther in the Iuture can thus simulate
diIIerential message transition times and
other sorts oI delays. The maximum
timestamp value Ior all actions is monitored,
and when no actions are leIt the Event loop
can be terminated ending the simulation
0 1 2 3 4 5 6 7 8 9
Action Action
Action
Action
0 1 2 3 4 5 6 7 8 9
Action
0 1 2 3 4 5 6 7 8 9
Action Action
Action
Action
Action
Action
Execution causes
two actions to be
inserted at timestep
3
Execution causes one
actions to be inserted at
timestep 4, another at
timestep 8
Execution causes two
more actions to be
inserted at timestep 8
P2P Journal, November, 2003
cycle. Thus messages can pass through the
network independently oI their TTL and the
simulation can be easily extended to handle
other types oI actions, such as node and
connection additions/Iailures.
Figure 2 shows an illustration oI the Event
table with Actions associated with diIIerent
timesteps. As the Actions are executed they
cause new Actions to be inserted at
subsequent timesteps in the event table, and
as the event loop iterates through the table,
they will eventually be reached and executed
themselves.
. imulation tatistics
The simulations themselves are controlled
Irom the imulation class which reads in
simulation parameters Irom properties Iiles
and runs the imulation, starting the event
loop a number oI times, and reIreshing the
network in between to clear caches and
global stats counters. A single query cycle
will generate a earch tatistics obiect that
will hold an arbitrary set oI statistics Irom
that cycle. DiIIerent sets oI statistics and
their labels can be passed in to the
earch tatistics obiect, which are in turn
added to tatisticsCollection obiect. Thus the
complete statistics Irom a series oI cycles are
stored in a single tatisticsCollection obiect,
which can then be passed to graph drawing
Iunctions based on the JFreeChart libraries.
As a result diIIerent simulations can use the
same statistics and graph drawing
Iunctionality, as we shall see in the next
section. For Iurther details on the NeuroGrid
simulator see http://www.neurogrid.net/.
5: Extensions
The extensibility oI the NeuroGrid
simulator can perhaps best be demonstrated
by reIerring to two recent extensions namely
a distributed Email and a DN simulation
both carried out by M. c. students using the
NeuroGrid simulator as the base Ior their
studies.
. : DN imulation
The largely hierarchical Domain Name
ystem (DN ) system is not an example oI a
P2P system but the basis Ior this proiect was
to see how the DN system might be
modiIied to best support a Content
Distribution Network (CDN). In this context
it demonstrates how the NeuroGrid base
classes can be extended to support arbitrary
network simulations.
Fig. 3: DNS operations supporting CDN network
(more details in text).
The general scenario Ior the simulation is
shown in Iigure 3 and described as Iollows:
The interaction starts at the client
merlot.cis.udel.edu . It asks its local DN
Name server to resolve a domain name. II the
local DN server doesn`t know the right
binding domain-name/IPAddress it has to
ask to the CDN DN server. Akamai DN is
the redirection server Ior that Content
delivery Network: its task is to decide which
surrogate is the most appropriate Ior that
speciIic client in that sub-network. The
message containing the binding is then
returned transparently to the client. In the end
the client can start its session with the right
surrogate to get the desired inIormation (such
as http pages, Iiles, streaming video, etc.)
P2P Journal, November, 2003
2
In order to create this simulation Irom the
NeuroGrid base, three diIIerent classes
extended the abstract Node class. Each
contained speciali ed data structures:
. DN NodeClient: contains address oI the
LocalDN Node Ior sending the request
message.
2. DN NodeLocal erver: contains a cache to
keep track oI the binding name/IPAddress
returned by the DN NodeCDN erver.
3. DN NodeCDN erver: contains list oI
surrogates to redirect client request.
A message handler was created Ior each
oI the above classes so that they could route
messages accordingly. The proiect
demonstrated the simulation oI a hierarchical
DN network was simple to deploy, and that
the combination oI Node and
Message andler classes could be used in a
generic Iashion.
.2: Distributed Email imulation
The aim oI the distributed email system is
to try and provide distributed email storage,
and email namespace through an overlay
network. The inIrastructure supporting the
transmission oI email messages is arguably
already a P2P system, but the motivation Ior
a Iully distributed approach is to try and
remove the centrali ed mailbox/account
provider as a single point oI Iailure.
The distributed email simulation used
Pastry, a Plaxton mesh variant, to provide
underlying routing and storage support.
Email messages are erasure encoded
(Weatherspoon & Kubiatowic , 2002) and
broken into Iragments beIore being
distributed through the network via Pastry
routing. Implementing the various aspects oI
the system involved extending a number oI
NeuroGrid base classes. Email search and
notiIication messages extended the
ContentMessage class. This allowed Ior
some code and variable re-use, however this
was not taken advantage oI to the maximum
extent possible. For example, while the
Email class itselI extended the Document
class and thus could be handled by the
Document variable in the ContentMessage,
additional variables were unnecessarily
added. This probably indicates the need Ior
improved documentation to alert developers
to how they can save themselves time and
eIIort by making Iull use oI existing support.
The Email class itselI extended the
Document class adding support Ior a data
si e and Iragments.
Perhaps most representative oI the code
re-use was the implementation oI the
EmailMessage andler, which overrode the
iniectMessage and handleMessage methods,
to switch to diIIerent methods depending on
the type oI incoming message, and thus
implement Pastry routing and other Ieatures
necessary Ior distributed email support. The
Email torageNode provided the additional
data structures necessary, and together with
the EmailMessage andler, could be used
seamlessly on top oI the existing Action
Event Iramework. Thus the developer could
make use oI the discrete event simulation,
and associated statistics & graph Ieatures,
while concentrating on the key aspects oI the
model being studied.
Fig. 4: Graph showing how usernames become lost
as nodes fail when usernames are replicated to
three nodes (more details in text).
One oI the key issues Ior a distributed
email system is to provide unique usernames.
P2P Journal, November, 2003
3
The maior diIIiculty is trying to prevent
username collisions. Replicating a complete
list oI all usernames to all nodes is
impractical, and having them stored in a
single location can lead to collisions when
that node is oIIline and unable to indicate the
existence oI that username. The alternative is
some intermediate degree oI replication.
Figures and show some username
persistence results generated by the
NeuroGrid system using the JFreeChart
packages, Ior diIIerent levels oI username
replication.
Fig. 5: Graph showing how usernames become lost
as nodes fail when usernames are replicated to
sixteen nodes (more details in text).
Both simulations were run on 000 node
networks with 2000 usernames inserted into
each. The simulations involved causing node
Iailures in the system and then checking to
see how many oI the usernames could still be
detected, given certain degrees oI replication
and the use oI repair methods. These repair
methods involve nodes that store replicas
being aware oI which other nodes have
copies and then acting to increase replication
iI these other nodes go down. In both graphs
the blue and green lines are derived Irom
simulations using repair, while the red and
blue indicate consecutive Iailures in the node
ID space while the green and yellow indicate
random Iailures.
The simulation results indicate that -
Iold replication oI usernames Ior a 000-node
network gives resilience in the Iace oI up to
0° random node Iailure, with or without
explicit repair methods. The results also
show the system is much less resilient in the
Iace oI consecutive node Iailure.
These results are presented mainly to
show the kinds oI graphs that can be easily
generated Irom the NeuroGrid simulator in
combination with the JFreeChart packages.
The results themselves are somewhat limited
as one might expect given the constraints oI a
Masters proiect. For these results to be seen
as valid simulation results, the same
simulations would need to be re-run a
number oI times to obtain a conIidence
interval, and thus take account oI variations
in the starting distribution. owever, this
kind oI analysis could now easily be
perIormed given the base provided by the
NeuroGrid simulator.
6: Discussion
In this paper we have looked at some oI
the principles oI simulation studies as well as
examining some oI the desirable properties oI
a P2P simulator. In addition we looked
through some oI the existing simulators as
well as taking a more detailed look at the
NeuroGrid simulator and how it was
extended to support diIIerent proiects.
The review oI the existing simulators
indicates that while packet level simulation is
desirable it is still somewhat expensive in
terms oI computing resources. Being able to
run an overlay network model on top oI an
existing arbitrary packet-level simulator is
clearly an advantage. In addition being able
to the plug the application layer aspect oI the
simulation into an arbitrary socket interIace
would also support testing oI the system in a
real network environment.
The appropriate use oI simulation
methodology cannot be over-stressed and
there is clearly an advantage to simulators
that provide statistical support or
visuali ation support. Both oI these Iacilities
P2P Journal, November, 2003
would beneIit Irom a standardi ed Network
Markup Language (NML) based on the
widely used XML standard rather than a
speciali ed markup Iramework.
The main diIIerence between P2P
systems and the lower level network systems
is the attempt to take the nature oI the system
content into account, rather than iust blindly
routing messages Irom A to B. Much oI the
promise in P2P systems seems to come Iorm
the idea that they might be able to take the
preIerences oI individual users into account.
II this is to be backed up in simulation there
is a need Ior a sophisticated and consistent
user/content modeling approach. This paper
has merely touched on some oI these issues
and we hope to expand on them in Iuture
papers and in the P2P simulation blog
http://www.p2p-simulator.org/.
7: Acknowledgements
Many thanks to David arman oI
Lancaster University and Paolo Gobbo oI
Turin University Ior making the material
Irom their M. c. proiects available Ior this
paper. Thanks also to Jon arris oI Carleton
University Ior detailed Ieedback on the draIts
oI this paper.
8: References
URL : http://www.isi.edu/nsnam/ns/
URL2: http://www.aisee.com/
Ahn, J. & Dan ig , P. ( ) peedup vs. imulation
Granularity. IEEE/ACM Transactions on Networking.
( ): 3- .
Babaoglu, O., Meling, . and Montresor, A. (2002)
Anthill: a Framework Ior the Development oI Agent-
Based Peer-to-Peer ystems, in proceedings oI 22nd
International ConIerence on Distributed Computing
ystems ICDC .
Baker, M. & Giuli, T. (2002) Narses: A calable
Flow-Based Network imulator. tanIord University
Technical Report. http://arxiv.org/abs/cs.PF/02 02
Bae ner, D., Lomow, G. & Unger, B. ( 0) im :
The transition to a distributed simulation. In Proc. oI
C MulticonIerence on Distributed imulation.
Clarke, I., andberg, O., Wiley, B. and ong T. W.
(2000) Freenet: A Distributed Anonymous
InIormation torage and Retrieval ystem. Proc. oI the
Workshop on Design Issues in Anonymity and
Unobservability. http://www.Ireenetproiect.org
Druschel, P., Rowstron, A. (200 ) Pastry: calable,
distributed obiect location and routing Ior large scale
peer-to-peer systems. In Proceedings oI the th
IFIP/ACM International ConIerence on Distributed
ystems PlatIorms.
e, ., Ammar, M., Riley G., Rai . & Fuiimoto, R.
(2003) Mapping Peer Behavior to Packet-level
Details: A Framework Ior Packet-level imulation oI
Peer-to-Peer ystems. In Proc. MA COT 2003
Joseph, . (2002) NeuroGrid: emantically Routing
ueries in Peer-to-Peer Networks. International
Workshop on Peer-to-Peer Computing, Pisa (2002).
Joseph, . (2003) P2P MetaData earch Layers.
econd International Workshop on Agents and Peer-
to-Peer Computing AP2PC.
Joseph, . & oshiai, T. (2003) Decentrali ed Meta-
Data trategies: EIIective Peer-to-Peer earch. IEICE
Transactions on Communications E -B ( ) : 0-
3.
Kant, K. & Iyer, R. (2003) Modeling and simulation oI
ad-hoc/P2P Iile-sharing networks. In Proc. oI Tools
2003.
Kant, K. (2003) An Analytic Model Ior Peer to Peer
File haring Networks. Proc. oI International
Communications ConIerence.
Law, A. & Kelton, W. (2000) imulation Modeling
and Analysis. McGraw- ill International eries.
Medina, A., Matta, I. & Byers, J. (2000) On the origin
oI power laws in internet topologies. Boston
University Technical Report.
Montresor, A. & Babaoglu, O. (2003) Biology-
Inspired Approaches to Peer-to-Peer Computing in
BI ON. In Proc. oI the 3rd International ConIerence
on Intelligent ystem Design and Applications.
Montresor, A., Di Caro, G. & eegaard, P. (2003)
Architecture oI the imulation Environment.
P2P Journal, November, 2003
Technical Report: D , BI ON proiect, University oI
Bologna.
Newman, M, trogat , . & Watts, D. (200 ) Random
graphs with arbitrary degree distributions and their
applications. Phys. Rev. E , 02 .
aroiu, ., Gummadi, P. & Gribble, . (2002) A
measurement study oI peer-to-peer Iile sharing
systems. In Proc. MMCN`02.
chlosser, M., Condie, T. & Kamvar, . (2002)
imulating a File- haring P2P Network. First
Workshop on emantics in P2P and Grid Computing.
toica, I., Morris, R., Karger, D., Kaashoek, M.F.,
Balakrishnan, . (200 ) Chord: A scalable peer-to-
peer lookup service Ior internet applications.
Proceedings oI the ACM IGCOMM '0 ConIerence.
http://www.acm.org/sigcomm/sigcomm200 /p 2.html
Ting, N. & Deters, R. (2003) 3L - A Peer-to-Peer
Network imulator. Third International ConIerence on
Peer-to-Peer Computing.
Weatherspoon, . & Kubiatowic , J. (2002) Erasure
Coding vs. Replication: A uantitative Comparison.
Proc oI the First International Workshop on Peer-to-
Peer ystems (IPTP 2002).
Zhao, B., Kubiatowic , J. & Joseph, A. (200 )
Tapestry: An inIrastructure Ior Iault-resilient wide-
area location and routing. Technical Report C D-0 -
, U.C. Berkeley.
Zhu, ., all, P. & May, J. ( ) oItware unit test
coverage and adequacy. ACM Computing urveys.
2 ( ):3 - 2 .
Zheng, X., Bagrodia, R. & Gerla, M. ( )
GloMo im: a Library Ior Parallel imulation oI
Large-scale Wireless Networks. In Proc. oI the 2th
Workshop on Parallel and Distributed imulations --
PAD '
Dr. Sam Joseph
is a research
associate at
the University
of Tokyo, where
he works on
peer-to-peer
and distributed
information
management
systems.
Dr. Joseph
received a
B.Sc. (Hons) in
physics with astrophysics at the
University of Leicester, UK,
followed by a M.Sc. in cognitive
science and natural language and a
Ph.D. in neural networks from the
University of Edinburgh, UK. He is a
recipient of the Raymond-Hide prize
for Astrophysics and a Toshiba
Fellowship. As part of the Toshiba
Fellowship, he worked on software
agents at Toshiba's Research and
Development Center in Japan. Dr.
Joseph continues to provide
consulting services ranging from
cognitive science to peer-to-peer
networking, to a number of Japanese
technology companies.
P2P Journal, November, 2003
Probabilistic Knowledge Discovery and
Management Ior P2P Networks
Dimitrios Tsoumakos
Department oI Computer cience
University oI Maryland, College Park
dtsouma(cs.umd.edu
Nick Roussopoulos
Department oI Computer cience
University oI Maryland, College Park
nick(cs.umd.edu
Abstract
The Peer-to-Peer (P2P) paradigm dictates a distributed
network model which enables the sharing oI resources
between its participants. In many cases, the location oI
these resources is a non-trivial task with network-wide
eIIects. In this work, we describe the Adaptive Probabilistic
Search method (APS) Ior search in unstructured P2P
networks. APS utili es Ieedback Irom previous searches to
probabilistically guide Iuture ones. Besides being a very
cost-eIIicient technique, it enables the distribution and
adaptation oI search knowledge over the network. Based on
that, we provide examples where this scheme can prove
useIul in more demanding environments.
I. INTRODUCTION
Peer-to-Peer (hence P2P) networking has been
growing rapidly in the last Iew years. Its success,
originally boosted by some popular Iile-sharing
applications (e.g., ), led to the emergence oI
numerous systems that utili e P2P technology
(e.g., 2 ).
These systems have had a considerable and
multidimensional impact. Focusing on technical
aspects, reI. reported that bandwidth
consumption attributed to popular Iile-sharing
applications amounts to a considerable Iraction
(up to 0°) oI the total Internet traIIic. o, while
there exists a vast amount oI untapped potential
around the Internet, current resource-sharing
applications consume huge amounts oI bandwidth.
P2P technology can play a key role in our eIIorts
to tackle both issues, iI careIully applied. In all
cases, the Iirst step involves the eIIicient
discovery oI the various resources inside a
network.
Today, the most popular P2P applications
operate on unstructured networks. The basic
characteristics oI these networks are the lack oI )
system control over obiect placement, and 2)
guarantees about search complexity and success.
We should also note that in such systems, peers
arrive and depart at will, connecting in an ad-hoc
Iashion.
In , we described the problem oI resource
discovery in unstructured P2P networks as well as
many proposed solutions. The shortcomings oI
most current methods relate to either excessive
message consumption (during obiect location or
index updates) or inability to adapt to dynamic
workloads and environments.
In our work with APS , we proposed a new
search algorithm that achieves high perIormance
at low cost. In APS, a node deploys k walkers Ior
obiect discovery, but the Iorwarding process is
probabilistic instead oI random. Peers eIIectively
direct walkers using Ieedback Irom previous
searches, while keeping inIormation only about
their neighbors. This scheme exhibits many
plausible characteristics, namely high success
rates, low bandwidth consumption and robust
behavior in Iast-changing environments.
In this paper, we describe this probabilistic
Iorwarding scheme based on walker
success/Iailure rates and how it can prove an
eIIicient solution Ior the general search problem.
We go Iurther to identiIy various other
knowledge resources that can be used by our
algorithm, both individually and iointly. It is a
Iact that many contemporary applications require
(or would beneIit Irom) the utili ation oI more
P2P Journal, November, 2003
Fig. . earch Ior an obiect using APS. The table depicts the change in index values, where X denotes the index value stored at node
X Ior neighbor relative to the requested obiect.
advanced Ieatures instead oI a single one. We
identiIy some possible cases and present
modiIications to APS in order to meet these goals.
II. THE APS METHOD
A. Algorithm Description
In APS. each node keeps a local index
consisting oI one entry Ior each obiect it has
requested. or Iorwarded a request Ior. per
neighbor. The value oI each entry reIlects the
relative probability oI this node`s neighbor to be
chosen as the next hop in a Iuture request Ior the
speciIic obiect.
Searching is based on the simultaneous
deployment oI k walkers and probabilistic
Iorwarding: The requester chooses k out oI its N
neighbors (iI k N. the query is sent to all
neighbors) to Iorward the request to. Each oI
these nodes evaluates the query against its local
repository and iI a hit occurs. the walker
terminates successIully. On a miss. the query is
Iorwarded to one oI the node`s neighbors. This
procedure continues until all k walkers have
terminated. either with a success or a Iailure. So.
while the requesting node Iorwards the query to k
neighbors. the rest oI the nodes Iorward it to only
one. In the Iorwarding process. a node chooses its
next-hop neighbor(s) not randomly. but using the
probabilities given by its index values. At each
Iorwarding step. nodes append their identiIiers in
the search message and keep a soIt state about the
search they have processed. II two walkers Irom
the same request cross paths (i.e.. a node receives
a duplicate message due to a cycle). the second
walker is assumed to have terminated with a
Iailure and the duplicate message is discarded.
Index values stored at peers are updated in the
Iollowing manner: When a node Iorwards the
request to one or k oI its neighbors. it pro-actively
either increases the relative probability oI the
peer(s) it picked. assuming the walker(s) will be
successIul (optimistic approach). or it decreases
the relative probability oI the chosen peer(s).
assuming the walker(s) will Iail (pessimistic
approach).
Upon walker termination. iI the walker is
successIul. there is nothing to be done in the
optimistic approach. II the walker Iails. index
values relative to the requested obiect along the
walker`s path must be corrected. Using
inIormation available inside the search message.
the last node in the path sends an update¨
message to the preceding node. This node. aIter
receiving the update message. decreases its index
value Ior the last node to reIlect the Iailure. The
update procedure continues along the reverse path
towards the requester. with intermediate nodes
decreasing their local index values relative to the
next hops Ior that walker. Einally. the requester
decreases its index value that relates to its
neighbor Ior that walker. II we employ the
pessimistic approach. this update procedure takes
place aIter a walker succeeds. having nodes
increase the index values along the walker`s path.
There is nothing to be done when a walker Iails.
Eigure 1 shows an example oI how the search
process works. Node A initiates a request Ior an
obiect stored at node E using two walkers.
Assume that all index values relative to this
P2P Journal. November. 2003
18
obiect are initially equal to 30 and the pessimistic
approach is used. The paths oI the two walkers
are shown with thicker arrows. During the search.
the index value Ior a chosen neighbor is reduced
by 10. One walker with path (A.B.C.D) Iails.
while the second with path (A.E.E) Iinds the
obiect. The update process is initiated Ior the
successIul walker on the reverse path (along the
dotted arrows). Eirst node E. then node A
increase the value oI their indices Ior their next
hops (nodes E. E respectively) by 20 to indicate
obiect discovery through that path. In a
subsequent search Ior the same obiect. peer A
will choose peer B with probability 2/9
30 40 20
20
. peer E with probability 4/9 and
peer G with probability 3/9.
B. Characteristics and Performance
Along the paths oI all k walkers. indices are
updated so that better next hop choices are made
with bigger probability. Our learning Ieature
includes both positive and negative Ieedback
Irom the walkers in both update approaches. In
the pessimistic approach Ior example. each node
on the walker`s path decreases the relative
probability oI its next hop Ior the requested obiect
along the search path. II the walker succeeds. the
update procedure increases those index values by
more than the subtracted amount (positive
Ieedback). ThereIore. both learning and
unlearning is perIormed during the search
process: Learning helps in achieving high
perIormance and discovery oI newly inserted
obiects. Unlearning helps our process adiust to
obiect deletions and node departures. redirecting
the walkers elsewhere.
As an immediate consequence oI that. more
knowledge is obtained with more questions. The
more Ieedback Irom the walkers. the more precise
the indices become. That particularly suits the
discovery oI popular obiects in the P2P network.
which. according to studies |8|. constitute over
60° oI all searches. Another similar observation
is that all nodes participating in a search will
beneIit Irom the process. This is a distinctive
Eig. 2. Direct comparison oI s-APS with various methods having
(a) similar messages or (b) similar hits
Ieature oI our method. with indices being
constantly updated using search results and not
aIter obiect updates. ThereIore. a node that has
never beIore requested an obiect but is 'near¨
peers that have done so. inherits this knowledge
by proximity.
APS requires no message exchange on any
dynamic operation such as node arrivals or
departures and obiect insertions or deletions. The
nature oI the indices makes the handling oI these
operations simple: II a node detects the arrival oI
a new neighbor. it will associate some initial
index value with that neighbor when a search will
take place. II a neighbor disconnects Irom the
network. the node simply removes all relative
entries Irom its memory. No action is required
aIter obiect updates. since indices are not related
to Iile content. The s-APS improvement Iurther
P2P Journal. November. 2003
19
reduces message consumption by adaptively
switching between the optimistic and pessimistic
strategies and minimizing the update messages. In
|7| we also experimented with various update
Iunctions Ior the index values.
Our main perIormance metrics are the success
rate. the average message consumption and the
number oI discovered obiects per query. Most
methods are eIIective in one or two oI these
metrics. but usually behave badly in the
remaining one(s). While there is no method that
meets all requirements. a good all-around
perIormance is desirable. To illustrate this point.
we present results where we compare s-APS with
the methods described in |10||14|. In Eigure
2(a) we show the success rate and hits per query
Ior all algorithms when they display very similar
message consumption. We would like our search
schemes to be located around the upper-right
corner oI this Iield. In Eigure 2(b) we display the
success rate and messages per query Ior the
algorithms when they discover a similar amount
oI obiects. In this case. we would like a scheme to
be located around the lower-right corner oI the
graph. We clearly notice that s-APS proves a most
reliable solution compared to these methods.
III. EXTENDING TO OTHER METRICS
The APS algorithm. as described above. utilizes
a single source oI knowledge. speciIically path
success or Iailure Ior requested obiects. We
showed that taking advantage oI this property
results in good perIormance Ior the general
resource location problem. The speciIic
characteristics oI the indexing scheme that we
would like to capitalize relate to the distributed
computation oI knowledge (knowledge can be
shared and reinIorced by multiple peers). small
memory and bandwidth requirements and the
ability Ior both learning and unlearning. An
interesting question now is how could this
indexing scheme be applied. so that more
inIormation can be utilized and more complex
requirements be met.
One example where APS can be readily applied
relates to the problem oI load balancing. This
problem is well known especially in the client-
server environment. In P2P networks. it is the
case that peers play the roles oI both client and
server. Data replication allows Irequent discovery
oI multiple peers that hold a particular obiect.
Naturally. not all peers provide services oI the
same quality. so they may diIIer in the number oI
concurrent connections that they allow. their
upload bandwidth. the quality oI content they
store. etc. Peers that share (locally or temporally)
popular content or peers that store large numbers
oI obiects usually receive a large number oI
requests. This results in perIormance degradation
as perceived by the requester nodes. The APS
scheme can be actively used to 'direct¨ searches
to diIIerent parts oI a neighborhood. thus
implementing a Iorm oI local load-balancing.
Peers can change index values and re-direct
walkers to non-congested parts oI the network. In
this case. index semantics will be associated to
congestion inIormation Ior the overlay links.
In reality. the decision oI whether to choose a
particular path/host/obiect is not based on a single
metric. APS can be naturally extended to take into
account network or application-dependent
inIormation. The interesting point in integrating
more inIormation is the Iact that the scheme
allows Ior its concurrent re-computation. The
more searches are perIormed. the more accurate
our indices become Ior a speciIic metric. As an
example. consider that we want to incorporate a
trust model into our system. Each peer holds a
value 1 . 0
i
t Ior each neighbor i. These values
can have the meaning oI how much this speciIic
peer is satisIied by its recent transactions with its
neighbors. OI course. index semantics can be
interpreted in many diIIerent ways. The great
advantage oI such a scheme is the ability to share
inIormation among peers (a peer that iust entered
the network will take advantage oI already built
indices in neighbors). Moreover. indices along
paths or located inside certain areas can be
aggregated Ior more complex computations (e.g..
computation oI trust between distant peers. voting
scheme inside a peer-neighborhood. etc).
OI course. any combination oI diIIerent (even
conIlicting) metrics can be incorporated. All or
P2P Journal. November. 2003
20
some oI the Iollowing parameters could be
considered (depending on the application): The
capacity oI overlay links. the 'trustworthiness¨ oI
each neighbor (however this may be deIined). its
sharing ability. network congestion. geographic
location. etc. The weight to be assigned to each oI
these properties is application-speciIic; in a
system where we worry about bogus content. we
should give preIerence to peers with high trust
values. II we plan on sharing large amounts oI
data (e.g.. ISO images Ior a new Linux
distribution). then we should aim Ior Iast. reliable
connections (high-capacity links together with
large peer uptime).
We believe that this cost-eIIicient scheme can
be a basis Ior many large-scale. distributed
communication protocols. Eor our Iuture work.
we plan on pursuing the directions mentioned
above and report on the relative advantages and
disadvantages compared to existing schemes.
IV. SUMMARY
In this article we presented the APS method Ior
search in unstructured P2P networks. APS
deploys probabilistically directed walkers by
utilizing inIormation Irom past searches. The key
characteristic oI the scheme is that it allows Ior
Iast. ioint learning. while being extremely
bandwidth-eIIicient. We went Iurther to propose
the extension oI knowledge integrated into the
Iorwarding/learning process. as well as some
possible applications that could beneIit Irom this
technique. We believe that this light-weight
probabilistic scheme can produce eIIicient
applications Ior many low-guarantee networks.
REEERENCES
|1| 'Napster website: http://www.napster.com.¨ .
|2| 'SETI(home web site:
http://setiathome.ssl.berkeley.edu/.¨ .
|3| I. Clarke. O. Sandberg. B. Wiley. and T. Hong.
'Ereenet: A Distributed Anonymous InIormation Storage
and Retrieval System.¨ Lecture Notes in Computer Science.
2001.
|4| E. Dabek. M. Kaashoek. D. Karger. R. Morris. and I.
Stoica. 'Wide-area cooperative storage with CES.¨ in SOSP.
2001.
|5| R. Dingledine. M. Ereedman. and D. Molnar. 'The Eree
Haven Proiect: Distributed Anonymous Storage Service.¨
Lecture Notes in Computer Science. 2001.
|6| 'The impact oI Iile sharing on service provider
networks. An Industry White Paper. Sandvine Inc..¨
|7| D. Tsoumakos and N. Roussopoulos. 'Adaptive
Probabilistic Search Ior Peer-to-Peer Networks.¨ in
P2P2003.
|8| J. Chu. K. Labonte. and B. Levine. 'Availability and
locality measurements oI peer-to-peer Iile systems.¨ in
SPIE. 2002.
|9| D.Tsoumakos and N. Roussopoulos. 'A Comparison oI
Peer-to-Peer Search Methods.¨ in WebDB. 2003.
|10| V. Kalogeraki. D. Gunopulos. and D. Zeinalipour-
Yazti. 'A local search mechanism Ior peer-to-peer
networks.¨ in CIKM. 2002.
|11| S. Daswani and A. Eisk. 'Gnutella UDP extension Ior
scalable searches (GUESS) v0.1.¨
|12| M. Stokes. 'Gnutella2 speciIications part one.¨
|13| C. Lv. P. Cao. E. Cohen. K. Li. and S. Shenker.
'Search and replication in unstructured peer-to-peer
networks.¨ in ICS. 2002.
|14| D. Menasc´e and L. Kanchanapalli. 'Probabilistic
Scalable P2P Resource Location Services.¨ SIGME1RICS
Perf. Eval. Review. 2002.
Dimitrios Tsoumakos
is a graduate
student in the
Computer Science
Department of the
University of
Maryland from where
he received his
Master's in Computer
Science in 2002. He
received his
Bachelor's and
Master's degrees in Electrical and Computer
Engineering from the National
Technical University of Athens (NTUA),
working with Dr. T. Sellis. He works with
Dr. N. Roussopoulos and he is interested in
distributed systems and algorithms for P2P
networks and the Internet.
His URL is http://www.cs.umd.edu/~dtsouma
P2P Journal. November. 2003
21
Editor`s Note
With a blink oI an eye. November has arrived. I started the Iall by spending a week and halI in
Seattle. Aside Irom working on proiects. I thought about what to write Ior the November issue.
Technically. this editor`s note was conceptualized on the airplane.
At work. I have been busy architecting several workIlow and business process management
(BPM) applications. A question suddenly hit me. Does P2P network have traIIic Ilow pattern?
And. can P2P applications be optimized to take advantage oI such designs? II yes. are there tools
to help model a P2P network and assist the design process? Eortunately. I received an article
about P2P simulation proiects and tools. (See 'An Extendible Open Source P2P Simulator¨
article)
Now. the iournal has three talented editors. Dr. Sam Joseph. University oI Tokyo. Daniel
Brookshier. senior technologist with Texas Instruments. and myselI. an architect with Nokia. we
are working on setting up a peer-review process that will help make Iuture articles more
meaningIul as well as carrying more relevant content. Having a peer-review process will be very
important as it allows editors. contributors. and reviewers to examine various submitted articles
and Iine-tune content and language to make it more meaningIul and easier to understand. It is
better to have three pairs oI eyes than one. Also. I am looking Ior a Iree Peer-to-Peer (P2P) co-
editing tool. which could be the most useIul approach Ior people to work in unison since 'eating
your own Iood¨. maybe the best demonstration Ior P2P technology. Also. building a P2P tool that
works with CVS or RCS will be a very interesting proiect. Perhaps. someone out there can work
on this.
Additionally. I saw an AD Ior the new Napster 2.0 when I was checking my web e-mail. Could
this mean that P2P has Iinally become commercially viable Ior the masses? Let`s hope we can put
litigation and copyright inIringement behind us and get something constructive out oI the
technology.
Einally. a couple days ago. I got a HP iPAQ 2200 (Xscale 400 Mhz processor) at a conIerence.
So. I have started playing with this new toy. As a P2P enthusiast. I have been looking around to
make it work with JXTA and JXME. Naturally. it requires Iinding a KVM Ior my pocket PC. So.
I browsed the web and saw a KVM listing web page. See below:
p://www.comp.lancs.ac.uk/computing/users/Iittond/ppciava.html
But. I was unable to Iind a Iree J2ME KVM Ior Pocket PC/Windows 2003 platIorm. II anyone
knows one. please let me know.
The pending explosion oI smart phones and integrated PDAs/e-mail devices may provide P2P
technology with many new receptive audiences. Blue Tooth and 802.11b/g network allow devices
to have wireless connectivity and dynamic discovery. P2P overlay network and protocol maybe
useIul as they enhance devices` ability to interact directly versus being dependent on a central
server. Eurthermore. P2P networks are designed to address the Iluctuating state oI relationships
particularly applicable in wireless networks where devices routinely come and go.
Dear Iriend:
The Peer-to-Peer Journal (P2PJ) is a bi-monthly iournal that opens a Iorum to individuals and hi-
tech Iirms who/which are interested in applying, developing, educating, and advertising in the
Iields oI Peer-to-Peer (P2P) and parallel computing. P2P Journal intends to be the gathering
place Ior people interested in reading and writing articles or discussing and chatting about P2P,
instant messaging (IM), collaborative computing, Iile sharing & distribution tools and protocols,
and parallel computing topics, such as grid and cluster. Experts or people who are directly
engaged in those the Iields could contribute articles in P2PJ.
The Editor-in-chieI is now inviting you or your Iriends to submit papers or letters Ior publication
at P2PJ. Articles, whitepapers, product reviews, discussions, and letters or short communications
to iournal are accepted. For writer's guideline, see
http://p2piournal.com/main/p2pwritersguideline.pdI
Once an article is accepted Ior publication, P2P Journal retains its copyrights, although
contributors may get a written permission Irom P2PJ Ior quotation or reuse his/her articles Ior
non-proIit purpose.
P2PJ shall become a medium helping connect people and entities and disperse useIul
inIormation. We believe that through building a gathering place where people can exchange
ideas and inIormation, everyone will beneIit Irom it. In the spirit oI sharing and Ireely
exchanging ideas, P2PJ has an online chat room that allows instant communication between
online visitors.
P2PJ encourages every contributor to attach his/her passport photo to the article as well as a
short bio. That way it can increase the author's visibility. We may also give some valuable giIt to
contributors Ior the recognition Ior his/her contribution to P2P computing Iields.
Best regards,
Raymond F. Gao
Editor-in-ChieI, P2P Journal
JJaannuuaarryy,, 22000044
HHaappppyy NNeeww YYeeaarr!!
BBoonn VVooyyaaggee ffoorr 22000044
Contents for January, 2004
The "Dark Side" And The "Force" Of The Peer-to-Peer
Computing Saga
by Luca Caviglione
This articles talks about P2P computing and key issues Irom both the ISP's and the
user's perspectives.
1OSE - A 1ava Open Source Exchange
by Denis Urusov
This is a proiect announcement Ior JOSE which is envisioned as a P2P exchange
Ior Java source code.
Editor's Note
by Raymond Gao
Call for Papers
Cover Image: "Sydney, Day and Night" - A super-impressionist view oI Sydney harbor
with time-multipexing, geological dislocation, and color/size variation. Oil on
Canvas (24x 48 inches), paintined by Raymond Gao, in Dec. 31, 2002.
(Only a part oI the original painting is shown here, some distortion due to
compression and resizing) People interested in the painting may touch with
Raymond Gao
Back Image: "Lucky Color Ior Love, Health, and Money" by Emanon Sevigohw. People
interested in his work, please visit
http://www.caIeshops.com/luckycolor.7952388
Editor-in-ChieI: Raymond Gao, raygao(comcast.net, editor(p2piournal.com
Simulation Editor: Sam Joseph, sam(neurogrid.com, sam(p2piournal.com
JXTA Track Editor: Daniel Brookshier, turbogeek(cluck.com
Contributing Editors: Luca Caviglione, Denis Urusov
P2P Journal is currently accepting articles Ior March, 2004 Issue
Copyright 2004: Unless with explicit written permission Irom P2P Journal, no part oI this iournal
may be recycled or reproduced in whole or parts.
1
12
17
22
P2P Journal, January, 2004
1
The ~dark side¨ and the ~force¨ of the peer-to-peer computing saga
Luca Caviglione
University oI Genoa Department oI Communications, Computer and Systems Science D.I.S.T.
Via Opera Pia 13, 16145 Genova (Italy)
Phone: ¹39-010-3532202, Fax: ¹39-010-3532154
e-mail: barone(dist.unige.it , luca.caviglione(cnit.it
Abstract
Recentlv. we are seeing a massive interest in
peer-to-peer (p2p) software bv home users.
People at home use this technologv mainlv for
file sharing. their computers acting as both
client and server. In addition. home users are
able to build "rendezvous" servers and start up
exchange communities. In other words. thev are
striving for a kind of "network emancipation"
that introduces a new concept of network usage.
On the other side. we can find Internet Service
Providers (ISPs) the onlv entities with the
power to constrain home users´ behavior. In
fact. evervdav there is a battle between the two
factions. users wanting to have liberal use of
their own bandwidth in wavs that thev want.
and ISPs. attempting to establish some rules
and control for certifving a "correct" network
usage. Consequentlv. two opposing forces
arise. the "Dark Side" and "1he Force". Which
is which? Judge for vourself bv reading this
paper.
Keywords: p2p, Iile-sharing, traIIic blocking
I. Introduction
Until recently, typical Internet users wanted to
obtain a number oI services Irom a central
server: e.g. news reading, video streaming, File
TransIer Protocol (FTP) and WWW browsing.
Recently new user behaviors have appeared
with many users oIIering bandwidth Ior such
things as hosting on-line games, building
gaming leagues, streaming music and
organizing exchange communities based upon
common interest. Furthermore, the user
interaction with the network is becoming more
complicated: security issues are now Iocal
issues (e.g. in e-commerce or on-line banking)
and "social" phenomena such as censorship or
legal action against users or "networking
attitudes" are driving the development oI
enhanced networking scenarios, where normal
users now desire more trusted and decentralized
architectures.
Currently, the TCP/IP |1| protocol stack is
widely adopted and deployed: it is the de facto
standard Ior telecommunication, networking,
and data transmission industries. In Iact, the
TCP/IP protocol suite oIIers diIIerent transport
services, allowing reliable data delivery or real
time traIIic distribution. In addition, a variety oI
diIIerent services have been implemented on
top oI TCP/IP: Real Time Transport Protocol
(RTP), FTP or Hyper Text TransIer Protocol
(HTTP). The IP layer oIIers capabilities Ior
bandwidth reservation, via the Resource
ReServation Protocol (RSVP) and Quality oI
Service (QoS) management, by using popular
and extensively tested approaches such as
Integrated Services (IntServ) or DiIIerentiated
Services (DiIIServ). In addition, the IP protocol
also oIIers security-oriented capabilities, with
the introduction oI the IP Security (IPSec)
protocol extension. It seems that the SOHO
(Small OIIice, Home OIIice) world is interested
in Iull IP convergence while Voice over IP
(VoIP) deployment is gathering pace, as
witnessed by the Iact that more commercial
devices are becoming available. There have
also been interesting developments in network-
related research Iields, particularly as regards
distributed algorithms and organization-related
issues |2|.
P2P Journal, January, 2004
2
Most ISPs oIIer Asymmetric Digital Subscriber
Line (ADSL) connectivity Ior end users on a
pay per traIIic, or on an always-on Ilat rate
basis. Both ADSL and the network
inIrastructure are engineered under the
assumption that users act on a client basis.
However, p2p applications (such as Iile sharing
programs) use both available streams. Actually,
p2p technology is increasing in popularity
amongst home users |3|. One might say that the
p2p model is the antithesis oI the client-server
communication paradigm. The client-server
paradigm is popular, eIIicient and has served
well since the birth oI computer networks and
service providing Irameworks, although one
can also argue that P2P computing was here
since the beginning: the "Iirst coming" oI p2p is
related to the birth oI the Internet and its key
technologies. OI course, there are some maior
problems in using a centralized architecture:
there is a single point oI Iailure, and malicious
actions can paralyze the normal service-
providing activities. In some cases perIormance
and throughput bottlenecks can be resolved by
deploying a cluster oI machines instead oI a
single central server. In principle the p2p
approach supports a Iault tolerant network with
multiple redundancy. However, p2p networks
still present some hazards: a pure p2p network
can be Iragmented due to multiple low capacity
links, e.g. the Gnutella crash oI 2000: mediated
p2p networks can suIIer when super nodes Iail.
Moreover, hybrid architectures, such as Napster
will lose Iunctionality iI centralized
components are removed.
In the past years, there has been an increasing
trend in decentralizing and distributing
Iunctionalities among many diIIerent machines.
The extension oI this trend has brought us to
p2p networking, where all the hosts have the
same capabilities and the same responsibilities.
To emphasize this aspect, all the entities
involved in this kind oI network are named
peers. In addition, p2p applications introduce
concepts related to the selI-organization and
interaction management oI diIIerent application
entities during the liIe cycle oI network-
oriented soItware. The server-centric world
does not oIIer this kind oI opportunity. The
introduction oI p2p technologies is enabling the
possibility oI creating a "iuxtaposed" network
over the physical one |4|. The intrinsic value oI
p2p technologies can now be Iound by looking
at their "second coming": p2p technologies
were widely adopted in Iile sharing applications,
as a countermeasure against actions aimed at
stopping Iile exchange practice. Owing to their
'hard-to-kill¨ characteristics, they have been
adopted as a reIerence model in a variety oI
Iile-sharing soItware. Moreover, this kind oI
network structure is becoming adopted in
diIIerent Iields, such as distributed computing,
instant messaging and distributed platIorms |5|.
Still, this kind oI architecture has some
problems: the topology is quite trivial, and there
is the lack oI a hierarchical organization,
bringing some maior diIIiculties in algorithm
development. The thriving activities oI P2P
networks and applications are a demonstration
oI its intrinsic resistance to shutdown. Actually,
they have survived lawsuits and attacks directed
by security experts. Even iI p2p networking
introduces structural improvements, it can also
lead to ineIIiciency, primarily due to content
and service delocalization. By using a p2p
architecture, there are some maior problems in
locating contents: the absence oI central
repositories prevent exhaustive content searches,
and security problems arise since there is no
centralized Iiltering oI content Ior worms, virii
and other malicious entities.
II. P2P applications for home use
There are several p2p applications available
today, which we group into Iive main
categories:
File sharing oriented software: this soItware
allows data exchange between remote users.
Each user shares one or more Iile Iolders Irom
their local Iile system. Compiling a complete
list would be a demanding task: diIIerent
soItware applications are released monthly and
they run under a variety oI diIIerent platIorms:
Apple Macintosh, Windows based PCs and
Unix/Linux/BSD boxes. They are developed
P2P Journal, January, 2004
3
using all available programming languages
today: many are programmed in C, C¹¹, but
Java is becoming quite popular thanks to its
intrinsic portability. While the implementations
may diIIer there are a number oI protocol
speciIications that are shared between diIIerent
sets oI clients. Some oI the most popular
applications include WinMx, Kazaa (especially
Ior the MicrosoIt Windows environment):
while Gnutella, eDonkey and OpenNap have
multiple client implementations on multiple
platIorms. Protocol availability is oIten related
to source-code or protocol speciIication
availability. WinMX and Kazaa are mediated
p2p networking technologies and rely on
proprietary protocols developed respectively by
FrontCode and FastTrack. The Gnutella
protocol speciIication is quite popular and
available Ior diIIerent platIorms: a popular
cross platIorm application written in Java is
Limewire. eDonkey is another popular protocol
ported in many operating environments: it is a
hybrid technology that relies on centralized
servers to perIorm Iile searches and user
paging. Finally, OpenNap is an open source
protocol speciIication, derived Irom reverse
engineering eIIorts on the original Napster
client.
Collaboration oriented software: allows
collaboration between remote users. Instant
Messaging (IM) soItware also Ialls in this
category. An interesting application is Jabber
|6| based on an open (eXtensible Markup
Language) XML protocol Ior the real-time
exchange oI messages between any two points
on the Internet.
Distributed computing oriented software:
allows the use oI remote peers resources
through the network and harnessing idle CPU
cycles. Probably, the most popular in this
category is SETI(Home |7|. It allows users to
cooperate through the network Ior scanning
radio tracks acquired by SETI (Search Ior
ExtraTerrestrial Intelligence) proiect telescopes
around the world.
Distributed platform-oriented software:
realizing a Iully distributed computing
platIorm. One oI the most active ongoing
proiects is Juxtapose (JXTA) |4|. The JXTA
proiect started in Sun Microsystems under the
leadership oI Bill Joy and Mike Clary. There
are also many other proiects such as planet-lab
and .NET, but JXTA has the advantage oI being
able to draw on a pool oI over 16,000 open
source developers.
Distributed Storage software: the most popular
proiect is Freenet |8|. The Freenet soItware has
been downloaded nearly 400,000 times |9|. Its
aim, as explained by the core team, is to create
a secure global inIormation storage system.
Furthermore, Freenet provides Ieatures
designed to maintain the anonymity oI all
parties and prevent any attempt to censor
content.
File Sharing appears to be the most popular p2p
soItware placing a huge demand on ISP
bandwidth, although there are also many users
oI distributed computing soItware like
SETI(Home |10|. Still, p2p applications
outside Iile sharing tend to consume more
'local¨ resources (i.e., CPU time and storage
resources) and they are not as widespread and
do not introduce such a heavy network usage.
Typically, ISPs have modeled home users as
'sinks¨: consumers oI network resources (e.g.,
streaming contents) rather than producers oI
heavy network loads. Thus P2P systems
introduce greater symmetry in the end users
traIIic that breaks the assumptions adopted by
ISPs. Probably this is the key problem that does
not allow a peaceIul liIe between the two
parties.
III. The ISP Perspective
Million oI users use the Internet everyday to
share digital materials in a totally independent
way, and this is creating a range oI pressing
issues Ior ISPs. The most important one is
whether exchanging copyrighted material is the
legal responsibility oI the service provider.
P2P Journal, January, 2004
4
Another aspect is related to the resulting traIIic
patterns, since Iile sharing applications produce
unpredictable traIIic around the network. In
addition, Iile-sharing soItware interacts and
organizes itselI without any respect Ior the
underlying network inIrastructure. Usually,
peers interconnections are established upon an
'interest based¨ mechanism rather than some
rational manner. II an interesting Iile is located
in the computer oI a user an interconnection is
directly established. This Iact will produce
some heavy traIIic patterns on inter-continental
or international links that are both expensive
and diIIicult to upgrade. According to The
Register, p2p Iile sharing activities accounts up
to 60 per cent oI the overall traIIic that Ilows on
any ISPs networks |11|. In a p2p network, the
complexity is shiIted to the border oI the
network. As previously stated, end systems or
end users act both as a client and as a server:
this Iact is well deIined by the Gnutella
developers, who call each peer oI the Gnutella
network servents (as a contraction oI client and
server). Is this shiIt oI complexity a real beneIit
Ior the network? Usually all the routing issues
are perIormed at the IP layer: each router
manages IP datagrams delivering them to their
destination using proper routing algorithms.
However, in selI-organized networks like those
created by p2p networks, there is another
routing hierarchy: the route is based on
application level routing. The physical network
topology is completely hidden so the peers
organize themselves by using only inIormation
available at the application level. Consequently,
there are two diIIerent networks overlapped: the
real network and an 'application level¨
network, called an 'Overlay Network¨ by many
academics. This situation produces unexpected
or unbalanced traIIic. These kinds oI
applications take decisions without any
consideration oI the underlying network
inIrastructure. Frequently, an ISP user connects
with a peer or a hub Irom another country,
rather than the nearest one or another active in
its same network. This pseudo random behavior
is reIlected in a highly chaotic traIIic.
The organization oI a p2p networks tends to
Iollow a power law scheme |12|. This is also
important Ior traIIic behavior. II a large hub
Iails, the orphan peers will search and re-route
themselves to other hubs to reIorm a connected
topology. Thus there will be a transient state
where a huge number oI peers will search Ior a
new network entry point. These kinds oI
unexpected peaks are not a good thing in a
telecommunications network. In the past typical
end users wanted to obtain some kind oI service
Irom a server: reading news, watching video,
FTP and WWW browsing. New user behavior
associated with overlay networks creates the
risk that routing decisions taken by a large
number oI peers will produce a massive traIIic
transition between two network boundary areas.
These transitions can lead to unbalanced and
unpredictable traIIic in the network
inIrastructure |13|.
Some ISPs oIIer Asymmetric Digital
Subscriber Line (ADSL) connectivity Ior end
users. However, ADSL and the network
inIrastructure are engineered under the
assumption oI users acting on a client basis in
contrast to p2p applications (such as Iile
sharing programs) that use both available
streams Ior uploading and downloading Iiles.
IV. The network administrator
perspective
From the perspective oI 'taming bandwidth-
hog applications¨, it is preIerable to queue with
aggressive rate limits during periods oI network
congestion than policing in the WAN¨ |14|.
Other techniques adopted in Campus networks
or in corporate networks concern Active Queue
Management (AQM) techniques or deploying
boxes allowing traIIic shaping and scheduling.
There are many methods to prevent users Irom
downloading p2p soItware rather than blocking
it during its normal liIe cycle: many
administrators perIorm URL blocking
preventing the download oI p2p clients. The
p2p community answer was quick and simple:
the p2p soItware is shared as a normal Iile on
P2P Journal, January, 2004
5
the overlay network or multiple mirrors are
established. A problem oI soItware
manipulation arises: in most cases, the author
no longer provides the soItware and there is a
risk oI modiIication, e.g. Troian horses. As is
oIten the case the solution is present in the
existing 'technology pool¨: most soItware is
released with an MD5 key that should be
checked by users beIore installing the soItware
(iI you are on a Unix box, try man md5).
Other methods have also been adopted: e.g.
computers are conIigured with small privileges
that impede soItware installation Irom the
users: or remote control soItware is installed,
such as Tivoli or Timbuktu, that can remotely
remove installed applications. Finally yet
importantly, the use oI p2p raises risks oI virus
inIections. II a user will download an inIected
executable there is no assurance that it is virus-
Iree. Certainly P2P misuse can sometimes be a
danger Ior corporate networks.
V. NATs
Nowadays, p2p applications are widely adopted
and are used among diIIerent network
technologies. Nevertheless, certain problems
remain when developing p2p applications. For
example, one reason maybe that p2p
applications rely on establishing a direct
connection. As explained and studied in the p2p
working group some oI the main problems are
that several issues and practice have reduced
the Internet s end-to-end transparency such that
addressing, discovery, communication and
other essential capabilities and services are
impeded or denied.
Two basic mechanisms account Ior much oI
this transparency reduction: Iirewall and NAT
devices. These two devices substantially inhibit
direct interactions with the other entity in the
communication. As a counter measure, p2p
developers propose a set oI 'traversal¨
solutions that will work without changing NAT
implementations, but acting on the p2p client
soItware. They also present three diIIerent
approaches that are today widely used in a
variety oI running p2p applications |15|.
1. A node behind a NAT or Iirewall initiates
communication with a node that is publicly
addressable. Systems such as Napster-
OpenNap and Gnutella Iall into this category.
2. Using a rendezvous server to provide a
repository Ior advertisement inIormation to
support discovery. JXTA Ialls into this
category.
3. Using a publicly visible node to act as
relay, or router, Ior blocked nodes. JXTA
also uses this approach.
The common idea in all the above approaches
assume that a third party host exists, running
special soItware can help nodes behind NATs.
All the presented solutions may be considered
impractical Ior the typical p2p home user but
many soItware packages introduced previously
in this paper are already implementing such
mechanisms. In Iact it is common to Iind some
options within the program that allow users to
act as a 'supernode¨ or as a 'primary
connection point¨ to route traIIic and queries to
nodes hidden by a NAT or Iirewall so that user
intervention is reduced to a minimum.
VI. Working around NAT
It is also true that broadband access is
nowadays widely requested by home users Ior
the purposes oI using Iile-sharing systems. It is
a recursive situation, where users want to
exchange a huge amount oI data in a reasonable
time, and consequently, demand a broadband
connection. This Iact introduces a 'virtuous
circle¨ so ISPs are able to Ilatten costs, due to
popular demand: it Iollows that ISPs are both
victims and causes oI their business model.
Home users require broadband access Ior
downloading Irom p2p networks, since normal
web browsing, IM, or e-mail is well served by
narrowband Internet access.
P2P Journal, January, 2004
6
However, this scenario is quite interesting. As a
'true storv¨, in Italy there is a quite innovative
service provider called FastWeb |16|, that
oIIers broadband access to its customers and, iI
available, Iiber to the home (FTTH) connection
at 10Mbit/s. Consequently, FastWeb users are
quite popular because many oI them host
servers or rendezvous points Ior a large number
oI p2p users. In addition, in coniunction with
the Linux phenomenon that allows building a
NAT in a Iew steps (namely IP-Masquerading
in the Unix/Linux world or Internet Connection
Sharing in Windows world), some interesting
conIigurations and soItware patches are being
developed. FastWeb is a public network that
oIIers both NAT-based access and public IP
access, although this may be applicable to other
ISPs around the world. The latter is more
expensive and aimed at business oriented users
rather than home users.
Most FastWeb users adopt the private IP
solution. Nevertheless, there are many users
that also deploy a NAT solution at home Ior
interconnecting diIIerent computers serving
diIIerent purposes: OpenNap servers,
multimedia streaming and so on. In this case,
we are in presence oI a nested NATs scenario:
the ISP uses NAT and the customer deploys
NAT.
As a prooI oI the timeliness and hotness oI the
topic, some FastWeb users developed a
program called mozzarella
1
|17|. Mozzarella is
a quite simple ANSI-C program (that runs
under Linux) allowing users to oIIer services in
a NAT-PAT managed network. In a Iew words,
the program uses a constitutive Ieature typical
oI the FTP protocol when working in active
mode. BrieIly, during an FTP session there are
two connections active: one is coupled with the
command path, while the other one is used Ior
the data path. When a client opens an FTP
connection in active mode the client connects to
the server to launch commands, while Ior the
data connection the server contacts the client.
Obviously, a router will take some inIormation
1
typical Italian cheese used as an ingredient Ior pizza
about the client-server route and 'build¨ a
temporary channel between the server and the
requesting client. ThereIore, the FTP client is
reachable outside the NAT-PAT network.
ThereIore, iI someone with a public IP address
builds an FTP server, by using this simple
program, users 'hidden¨ by a NAT-PAT will be
able to oIIer services.
FastWeb users report in many Iorums that, by
opening 9 TCP connections against 3 FTP
servers and issuing 36 PORT commands per
seconds, they can establish 10 incoming
connection per seconds. Some have reached a
peak oI 41 established connections reaching a
throughput oI 1200 kbit/s.
Code 1. depicts, (code released under GPL,
http://www.gnu.org/licenses/gpl.html) a portion
oI the mozzarella code, speciIically the main
FTP handler loop. In the code there are many
Iunctions to handle Itp procedures, such as
ftp_connect, ftp_login and ftp_port
(respectively Ior CONNECT, LOGIN and
PORT commands).
Basically, the 'core¨ is conIined in the Code 1.
snippet: there are also (except main( ) ) some
Iunctions to parse parameters Irom the
command line (e.g., target host and port) and a
bit oI logic to fork ( ) mozzarella, augmenting
the 'PORT throughput¨.
P2P Journal, January, 2004
7
Code 1. Basic FTP connection handler loop
int childmain(char *host, int ftpport, char *user, char *pass,
int *local_ip,int port, int pps)
{
int c, d = 0, a;
while(1) {
if((c = ftp_connect(host,ftpport))<0 && !d)
exit(1);
else while(c < 0) {
c = ftp_connect(host, ftpport);
sleep(1);
}
fprintf(stderr, "+ Connected...\n");
dup2(c, 0);
dup2(c, 1);
if((a = ftp_login(user, pass))<0 && !d) {
shutdown(c, 2);
close (c);
exit(1);
} else while(a<0) {
a = ftp_login(user, pass);
sleep(1);
}
fprintf(stderr, "+ Logged in...\n");
d++;
while(1)
{
//fprintf(stderr, "+ Sending...\n");
usleep(ONESEC/pps);
if(ftp_port(local_ip, port)<0) {
shutdown(c, 2);
close(c);
break;
}
}
}
}
P2P Journal, January, 2004
8
There are two classes oI users Ior this
technology: 'respectIul¨ users who utilize an
ad-hoc FTP server Ior this technique (but
located outside the private domain), or a less
respectIul group that uses randomly selected
FTP servers. II you are the administrator oI one
or more FTP servers and you are experiencing a
large amount oI simultaneous FTP requests
maybe your server is the designed target Ior this
kind oI technique. Nowadays, many FTP
servers deny access to FastWeb users.
VII. Port Blocking
Port Blocking is one oI the most widely used
techniques aimed at reducing Iile-sharing
generated traIIic. Many available programs use
a set oI 'well-known¨ ports to exchange control
inIormation and data. By blocking these ports,
ISPs isolate their users Irom the p2p-network.
This technique was adopted by many ISPs to
impede connection to Fast Track p2p network.
This countermeasure is simple and works well
until soItware developers or remote users.
Select another set oI ports. Moreover, not all
home users are so skilled as to be able to
change the port number: actually, this is only a
work-around rather than a deIinitive solution.
VIII. Blocking Traffic
A more sophisticate solution is one aimed at
analyzing and selectively blocking traIIic. As
previously explained, port blocking techniques
are 'dumb¨: traIIic is blocked only by
exploiting a statically typed port rather than
perIorming a dynamic, run-time based action
against undesired traIIic. One oI the most
interesting proiects is p2pWall |18|. The aim oI
this soItware is to support the blocking oI
traIIic generated by many p2p soItware
applications such as FastTrack and WinMX.
One oI the key problems encountered when
trying to regulate access to the public Internet is
that many Iile sharing clients establish an
'outbound¨ connection that will be used to
accept 'inbound¨ connections through the
opened socket. This problem is relevant
because the Iirewall is unable to block the
resulting in-bound connection: this trick
establishes a kind oI limited, reverse tunneling
that exploits an allowed TCP connection.
The mechanism introduced by the p2pwall
proiect is quite simple but powerIul. The
program interacts with Linux s Iirewall iptables
(on Linux, see man iptables) using the QUEUE
target. BrieIly, it analyzes the packets ready to
be Iorwarded and decides whether to discard a
packet or not by understanding some basic
characteristics oI the FastTrack protocol. The
soItware is tightly coupled with the Iirewall
Iacility: the Iirewall is assumed capable oI
blocking inbound connections: p2pwall will try
to block outgoing connections. II properly
conIigured the sum oI these two approaches
will secure the network.
IX. Popular Countermeasures
One oI the most popular protocols adopted in
p2p networks is the one developed by
FastTrack. One can Iind a variety oI clients that
rely on the FastTrack protocol: Kazaa (also the
Kazaa Lite variant), iMesh and GrokSter. The
FastTrack protocol adopts some interesting
countermeasures to achieve 'hard-to-kill¨
characteristics. To mention some oI the most
interesting ones, the FastTrack protocol uses:
random port number, peers connecting
randomly with other peers, a 'peers paging¨
logic that does not rely on a central directory
and network-critical traIIic that is encrypted.
a. Random Port Hopping
Random port hopping is a simple but popular
technique. AIter a connection is established, the
data Ilow is periodically moved Irom the
current port to another. In addition, when a peer
attempts to connect to the network, it Iirst tries
a port and iI the connection attempt Iails, it tries
another one, randomly selected Irom a preIixed
port pool. Naturally knowing the port range
utilized allows this approach to be compensated
Ior, but sometimes a large set oI ports is
adopted. In addition, sometimes well-known
P2P Journal, January, 2004
9
ports are used: consequently, legal services may
also be blocked.
b. Data Encryption
Most p2p soItware available use an html-like
system to exchange inIormation, such as
handshaking with other peers or super-nodes,
search queries or download requests. This
traIIic can be analyzed in order to establish a
'protocol Iingerprint¨ in order to block traIIic
or prevent p2p usage. One oI the most popular
countermeasures is one that ciphers the traIIic
Ilow in order to prevent pattern recognition and
traIIic spooIing to Iorce peers to leave the net
or misbehave.
c. Http tunneling
Http tunneling is another technique adopted
when a Iirewall impedes traIIic Ilow. An http
tunnel oIIers the possibility oI encapsulating
data inside an http Ilow and route it through a
Iirewall. Usually, web browsing is allowed in
organizations networks and Ior home users:
consequently, the Iirewall is conIigured to let
http traIIic Ilow. This technique brings to an
abuse oI the port 80, but allow masquerading
illicit traIIic under the guise oI normal web
browsing. Naturally the amount oI traIIic
reveals the true nature oI the communication: 5
Gigabytes oI traIIic on port 80 per day should
lead to some investigation
d. Dynamic DNS Bindings
In the Internet, there are three interesting types
oI IP addresses: private IP addresses, static-
public IP addresses and dynamic-public IP
addresses. Most providers oIIer Internet
connectivity by using a dynamic IP schema.
When a user requests a connection, a DHCP-
based server sends back a public IP address,
aIter some authentication procedures. Dynamic-
public IP addresses oIIer a beneIit due to their
mutable characteristics: it is not possible to
block permanently this kind oI addresses
because the owner changes over time.
Nevertheless, a dynamic addressing scheme
introduces some diIIiculties in Iinding network
entry points or rendezvous servers: a list oI
available servers and address mappings must be
maintained. This introduces some problem also
Ior Iile sharing: usually some queuing
mechanism is adopted. A peer enters another
peer s remote queue and it is called back when
the queue is exhausted and it can start
downloading. But iI the IP address is no longer
associated within a peer, having been released
and reallocated by the network, the new IP
owner will receive undesired callback data.
Network addressing scheme mutability
introduces some problems in creating some
listing oI mediation points, but many
organizations oIIer a dynamic DNS service.
This service allows (by installing an ad-hoc
daemon or providing inIormation by hand) your
location to be made consistent, identiIying your
peer with a Iixed name that points to a variable
IP address. Dynamic DNS oIIers another
degree oI Ilexibility in organizing peers
localization and naming.
f. The Poisoned DNS
Under this sinister name, we can Iind such
strategies devoted to analyzing and Iiltering
DNS traIIic and requests. The key assumption
is that application developers do not 'hardcode¨
the IP address oI a 'kickstarter¨ inside the
application code, but they use DNS name
entries (e.g., messenger.where.com,
peercaches.boh.org, etc). This technique is
based on intercepting DNS queries rather than
blocking a server s IP address (that could
periodically change). The Poisoned DNS
approach consists oI sending invalid DNS
inIormation back to the unsuspecting user. To
exploit this technique you must deploy at least
two DNS servers: one that is under your control
and another one that will resolve valid DNS
queries. This approach is quite simple since
nowadays a DNS server is both cheap and
quick to deploy (Linux implements very good
DNS soItware, bind). In the Iuture maybe some
developers should 'hardcode¨ the IP address,
rather than DNS names, but iI an address will
be blocked, a new soItware download will be
P2P Journal, January, 2004
10
necessary. Another possible system is to bypass
the DNS service and build a distributed and
independent name service (e.g., ICQ was the
Iirst program that in some ways bypassed the
classical DNS service): this is complex and
resource intensive. Nowadays, many p2p
services rely on 'server lists¨ to Iind an entry
point to the p2p network: iI all the servers
appear dead, only a download oI a Iew
kilobytes is needed. The download can be
perIormed at home or in the oIIice (or
university) iI the network is under control.
X. IRC: bots, bouncers and whatever
Internet Relay Chat (IRC) was born as a
centralized, Iull-text service, Ior chat and
messaging purpose. BrieIly, the IRC protocol
relies on the client-server architecture. During
its deployment, the protocol was updated with
the capabilities oI Iile transIer Iunctions.
Obviously, this Ieature introduces bandwidth
bloating on the server-side. In this perspective,
the protocol was extended with a Client-to-
Client Protocol (CTCP) |19| capability that
resembles the p2p approach. Nowadays, IRC
networks are oIten used as a Iile-sharing
network: IRC clients implement automated
procedures by exploiting some script services
(via bots) and oIIer services a la Iile server (F-
Serve). In addition, a bouncer service is
provided. A bouncer is quite similar to a proxy:
by doing so, it is possible to route IRC traIIic to
another machine, allowing anonymity and
preventing port blocking issues. IRC Iile
exchange practice is oIten ignored by ISPs.
XI. Conclusions
In this paper, we have presented some possible
p2p usage Irom SOHO and why problems arise.
In addition, we have analyzed some deIensive
maneuvers and countermeasures proposed by
the two Iorces, the users and the ISPs, who are
involved in the modern Internet. Now it
remains Ior you to iudge which side is which!
Acknowledgements
To Mr. F., Ior his patience and valuable
suggestions.
Bibliography
|1| D. E. Comer, "Internetworking with
TCP/IP, Volume I: Principles,
Protocols, and Architecture", Prentice
Hall International Editions, Englewood
CliIIs, NJ, 1991.
|2| Some SpeciIic Proiects in Collaborative
Computing,
http://dsonline.computer.org/collaborati
ve/proiects/proiects.html
|3| Peer-to-peer Harnessing the Power oI
Disruptive Technologies, edited by
Andy Oram, O Reilly, March 2001.
|4| Proiect JXTA, http://www.ixta.org
|5| MicrosoIt .NET,
http://www.microsoIt.com/net/
|6| Jabber SoItware Foundation,
http://www.iabber.org/about/generalIaq.
html
|7| SETI(Home scientiIic experiment,
http://setiathome.ssl.berkeley.edu/
|8| The Freenet proiect,
http://Ireenet.sourceIorge.net
|9| I. Clarke, O. Sandberg, B. Wiley, T.W.
Hong, 'Freenet: a distributed
anonymous inIormation storage and
retrieval system,¨ in Workshop on
Design Issues in Anonymity and
Unobservability, ed. by H. Federrath.
Springer: New York (2001)
|10| Seti(home stats, available on-line,
http://setiathome.ssl.berkeley.edu/totals.
html
|11| The Register USA, on-line article
available at
P2P Journal, January, 2004
11
http://www.theregus.com/content/6/262
87.html
|12| L.A. Adamic, R.M. Lukose, A.R.
Puniyani and B.A. Huberman,¨Search
in Power Law Networks¨, Physical
Review E, Volume 64, 046135, pp.
046135-1 046135-8
|13| Ripeanu et al, 'Mapping the Gntuella
Network ¨, Internet Computing Jan/Feb
2002
|14| M. Montan z, 'Deploying QoS in the
Enterprise¨, Cisco Packet Magazine,
vol.14, no.4, Fourth Quarter 2002, p.34.
|15| Peer To Peer Working Group,
'Bidirectional Peer-to-Peer
Communication with Interposing
Firewalls and NATs¨, DraIt Revision
0.095, August 17 2001 p.16,
http://www.peer-to-
peerwg.org/tech/nat/Docs/NATWhitePa
perv095.pdI
|16| FastWeb Internet Service Provider,
http://www.Iastweb.it
|17| BFi numero 10, anno 4 - 30/09/2001 -
Iile 13 di 18, available on line (only in
Italian),
http://www.s0Itpi.org/bIi/online/bIi10/B
Fi10-13.html
|18| P2PWall - IPTables blocking oI P2P
traIIic, http://www.lowth.com/p2pwall/
|19| CTCP (Client To Client Protocol),
http://www.irchelp.org/irchelp/rIc/ctcps
pec.html
About the Author
Luca Caviglione holds a Laurea degree in
Telecommunication Engineering Irom the University oI
Genoa, Italy. He works in Italy both Ior C.N.I.T. (Italian
National Consortium Ior Telecommunications) and Ior
DIST-University oI Genoa. His main interests are IP-
networks, GRID Computing, Unix Systems and p2p
networking. He loves King Crimson. Photo taken in
Lisbon.
.
P2P Journal, January, 2004
12
Project Announcement
3OSE - A 3ava Open Source Exchange
http://iose.ixta.org
JOSE (stands Ior Java Open Source Exchange) is envisioned as a peer-to-peer network
that allows developers to search, view and download source code made available by other peers.
Denis Urusov
mailto:urusov(optonline.net, mailto:durusov(yahoo.com
I. The need for P2P-based source code
exchange network
As developers we oIten turn to diIIerent
sources looking Ior programming tricks,
design pattern implementations and best
practices sample usage. Consider the
Iollowing common scenarios - you have
stumbled across an interesting algorithm, but
the time is pressing and you don t have time to
code it up. You ve iust downloaded a new
API, along with Javadoc and user guide, but
there is no sample implementation! You ve
never worked with iava.util.preIs package
(new in JDK 1.4) and you would really like to
see how people use it in real liIe. This list
could go on and on the bottom line is a
developer needs to quickly Iind source code
that deals with a programming challenge at
hand.
The very Iirst step many developers make is
trying to squeeze as much as possible Irom the
available documentation. Then, usually, a
search engine enters the scene and brings
hundreds or thousands oI query result records
to the table. Browsing through the results, you
might be lucky to get some relevant
inIormation such as articles Irom open source
development portals, messages Iorums and
news groups. Would you actually get the
source code you were looking Ior? Maybe.
Would you have to get through tons oI
garbage? Certainly. Alternatively, you could
Ietch a book, call on a Iellow developer, post a
news message crying Ior help all oI these
methods do work, but you are bound to lose
precious time.
Wouldn t it be great iI there were a place
known and available to everyone, maintained
by developers Ior developers and containing
iust what you want pure source code and
libraries?
One solution to the problem could be a global
peer-to-peer network that allowed its
participants to Ireely exchange Java source
code, libraries, conIiguration and
documentation Iiles. Reminds you oI Kazaa,
Orpheus and other Iile-swapping networks,
doesn t it? Well, the analogy here is perIectly
valid, except Ior the Iact that instead oI trading
media Iiles, peers would be sharing source
code and applicable supporting materials. The
targeted audience oI such network would
consist potentially oI:
Individual developers, wishing to share
and exchange Java source code containing
reIerence implementations, algorithm
implementations, best practice usage
examples, development hints and tricks,
Javadoc, white papers etc.
Java open source development
communities, such as www.sunsource.net,
www.apache.org and many others.
SoItware development companies,
promoting their products and services.
Schools and universities, exchanging
academic proiects data.
P2P Journal, January, 2004
13
Introducing a p2p open source code exchange
network is a great way to popularize the open
source movement and promote Java as
programming language. Given the large
number oI both corporate and individual Java
development centers spread around the globe
there would always be enough peers to satisIy
searches. Incredible popularity oI p2p media
exchanges is a good prooI oI concept.
II. 3.O.S.E (3ava Open Source
Exchange)
JOSE is envisioned to become a global peer-
to-peer network that will allow its participants
to search, view and download source code
Iiles and supporting resources.
A peer in JOSE will optionally expose a local
directory structure containing Java source
code Iiles, iar libraries, documentation and
conIiguration Iiles and so on. One oI the
Iunctional requirements Ior JOSE client
implementation is to allow a peer to choose
what should be open Ior access and what
should be kept private. The decision would
largely depend on environment in which JOSE
client is set up in - IT department oI Iinancial
corporation, an open source development
company or an academic organization.
The draIt version oI JOSE speciIication
proposes the Iollowing types oI searches
against the exposed code base:
Package and tvpe name search (search bv
full or partial name of a package. class or
interface name)
Full text source code search
Full text Javadoc search
Librarv (JAR) name and version search
Once search results are returned, a peer would
be able to browse, view and download Iiles
provided by other peers. The Iollowing types
oI downloads would be oIIered:
1. Single Iile download (get the Iile you are
viewing)
2. Package level download (get all the Iiles
Irom the current package and sub-packages)
3. Application/root level download (get the
entire application the Iile(s) you are viewing
belongs to)
The immediate goal oI JOSE proiect is to
provide speciIications Ior the client module
and communication protocols. Once this goal
is achieved, the materials will be made
available to the public, so that people could
start writing their own implementations oI
JOSE client modules, which could be
embedded in IDEs as plugins, run as
standalone programs, exposed as Web
Applications etc. JXTA technology allows
any connected device on the network ranging
Irom cell phones and wireless PDAs to PCs
and servers to interact with other peers and
resources directly, even when some oI the
peers and resources are behind Iirewalls and
NATs or are on diIIerent network transports.
This means that JOSE client module
installations will not be limited to
workstations and servers. One would be able
to search Ior source code Irom any device
connected to the network. There is nothing in
the JOSE speciIication that mandates a peer to
share anything in order to be able to search
and download.
Even though JOSE, as the name implies, was
originally thought oI as a source code-sharing
network Ior Java developers, it does not have
to stop there. II designed properly, it should be
able to accommodate needs oI programmers
who use other languages.
JOSE is currently setup as one oI JXTA
proiects. You can visit the proiect home page
at http://iose.ixta.org. The proiect is at a very
early stage oI deIining Iunctional requirements
speciIications Ior client module,
communication protocols and standards. The
P2P Journal, January, 2004
14
proiect team would greatly appreciate any
kind oI Ieedback design proposals,
Iunctional requirements suggestions and so
on. Please Ieel Iree to send your comments to
the proiect owner at durusov(ixta.org. You
are welcome to request a role in the proiect by
going to the membership assignment page -
http://iose.ixta.org/servlets/ProiectMembershi
pRequest. (JXTA registration is required).
III. Why P2P (centralized-decentralized
topology)?
SelI-sustainable global peer-to-peer networks
have proven to be very eIIective in both being
able to support eIIicient traIIic Ilow and
provide quick access to distributed content.
There are several topologies that are
commonly used to architect p2p networks, the
basic ones are Ring, Centralized, Hierarchical
and Decentralized. In the real world, however,
p2p networks are set-up using hybrids oI the
topologies mentioned above.
3 3O OS SE E i is s d de es si ig gn ne ed d t to o r re el ly y o on n a a c ce en nt tr ra al li iz ze ed d- -
d de ec ce en nt tr ra al li iz ze ed d t to op po ol lo og gy y. .
A signiIicant number oI developers are
working behind Iirewalls, and it would make
sense to run a Iew super-nodes within the
organization with all the participating
developers pointing their local JOSE clients to
the super-nodes.
The Iollowing is a quote Irom Nelson Minar s
review oI most popular p2p topologies -
' the amazing story is the scalability oI this
|centralized-decentralized| hybrid. Internet
email runs very well Ior hundreds oI millions
oI users and has grown enormously since its
initial design. FastTrack-based systems have
grown very quickly with none oI the
slowdowns that plagued Napster or Gnutella
in their growth. There is growing interest in
this kind oI hybrid topology as an excellent
architecture Ior peer-to-peer systems¨.
Figure 1 Image taken from Distributed Systems
Topologies by Nelson Minar
Thanks to the nature oI decentralized p2p
network, there is nothing to be maintained - no
servers, no databases, and no user
administration. There would be no governing
body. Such networks, although not
manageable, are extensible, Iault-tolerant,
lawsuit-prooI and scalable.
IV. P2P vs. single portal approach
One might wonder whether peer-to-peer
network is the best choice to accommodate the
global source code sharing system. Why not
use a completely centralized solution, such as
source control storage hosted on a single
server and accessible via a web portal, letting
all the interested parties upload their shareable
source code into a central repository and make
it available Ior everyone to search and
download? Consider the pros and cons oI the
centralized solution approach:
Pros:
I. Better search results - iust like
Napster s searches were much more
eIIicient that ones run through Kazaa s
network, searches against centralized
source code repository will be Iaster and
more consistent that the ones executed in
decentralized p2p network. There would
P2P Journal, January, 2004
15
be no issues with peers going on and oII-
line at will.
II. No client side software required -
exposing the search Iunctionality via http
interIace would let anyone equipped with
an Internet browser access the central
repository. However, this could be looked
at Irom a diIIerent angle, especially by
those who want to search right Irom their
IDEs.
Cons:
I. Having to maintain the shareable
code in the central repository - this
means that anyone, be it an individual or a
company, who wants to share source code,
would have to take care oI uploading the
code to the central server and keeping it up
to date. For example - iI one decides to
stop sharing a portion oI the code, he or
she would have to access the central server
and physically remove the code Irom the
repository. In other words, in addition to
keeping the source code in local version
control system (like CVS) developers
would now have to also maintain the code
in the repository on the central server.
In the p2p approach, all one has to do is
point the JOSE client to the shareable code
base. II the code changes or gets removed,
the client module will automatically know
about this and no extra steps on user s part
will be required.
II. Maintenance and ownership of
central server(s) - using centralized
solution implies that someone would have
to accept the responsibility Ior ownership
and support oI a central server, a system oI
mirrors, address load balancing and Iail-
over capabilities.
Assuming that the JOSE initiative does
reach its global scope and the number oI
the participants reaches tens or hundreds
oI thousands oI users, there maybe
potentially an operational problem
associated with storing massive amount oI
data, maintaining highly dynamic code
base, providing Iast access Ior very large
numbers oI search, and servicing upload
and download requests. Even iI there is an
organization or a group that agrees to
support the hosting oI such non-trivial Iile
server and Itp server capabilities, it is still
yields to no-maintenance p2p approach.
Having looked at the cons and pros, we must
keep in mind that JOSE. envisioned as a p2p
network with centralized-decentralized
topologv. allows combined central storage
solution with pure p2p approach. A very
good scenario to consider would be using
widely popular open source communities,
such as Source Forge and Apache that have
been around Ior a while now and have proven
to be excellent centralized solutions Ior open
source development proiect hosting. However,
this does not mean that both communities
cannot participate in p2p-based JOSE
network.
Indeed, iI we think out oI the box and view
Apache and SourceForge simply as 'big¨
peers, we see that all it takes Ior them to
become participating peers in JOSE is to
install the JOSE client side soItware and point
it to the proiects CVS directories. With a very
minimal eIIort the existing source code
repositories oI Apache and SourceForge will
become available to other JOSE peers.
What we are saying here is that properly
selected p2p topology Iacilitates minimization
oI the source code sharing eIIort. II an
individual developer wishes to become a
JOSE peer he or she is Iree to so, iust as the
open source giants are.
P2P Journal, January, 2004
16
It is very likely that existing open source
portals will lead initial task oI making JOSE
happen aIter all, they are always online, they
have both code base and inIrastructure that
supports mass storage and traIIic. Thus, it is
possible that JOSE will end up having two
groups oI peers the ones that will mostly
store the source code (open source portals and,
say, schools) and the ones that will mostly
search the network (individual developers).
Advantage that JOSE brings to the table is a
single standard protocol that all the peers will
use.
V. What`s next
As mentioned above, at this point the proiect
team dedicates 100 oI its time to
requirements gathering and speciIication
deIinition, trying to pave the road Ior the open
contest Ior client module implementation.
In the long run, there will be marketing
workload associated with promoting JOSE
and getting soItware industry players
interested in the proiect. Development
communities are target oI aggressive
marketing campaigns run by soItware
development giants, who are luring developers
into using products such as Integrated
Development Environments (IDEs), testing
systems, code analyzers and optimizers. AIter
all, developers are the ones to cast the key
vote in the J2EE against .NET battle.
Ideally, in the near Iuture, developers will be
accustomed to use JOSE Ior source code
exchange iust as Internet users are now using
Google Ior search and Yahoo Ior driving
directions. There is a lot oI work to be done:
and, the proiect will need all the help and
attention it can get in order to succeed
About the Author
Denis Urusov has about 10 years experience oI working
in soItware industry, mostly Iocusing on Java
commercial applications. He Ieels that P2P is a very
promising area in computing and would like to
contribute to its development.
His employment record includes Bear, Stearns and Co.,
Hewlett-Packard, and Federal Reserve. He has a BA in
computer science Irom NYU.
P2P Journal, January, 2004
17
Editor`s Note
During the past two months, I have observed many interesting events taking place in the P2P space.
There were several new P2P applications and betas released. They included Skype (http://skype.com),
Kappie (http://kappie.com), JXTA Go (http://go.ixta.org), 3°, (http://threedegrees.com), GLOO
(http://www.gloolabs.com)and much more. Between working on proiects at my day iob and reviewing
articles, I test-drove Kappie and Iound it to be highly interesting. Kappie resembles a personal tabloid.
It allows people to publish their thoughts or news clippings on the web. Best oI all, it works across
Iirewalls. I even posted recent issues oI P2P Journals online. Keep a look out Ior it.
Additionally, P2P has been garnering increased public attention. Recently, a new group called the
Content ReIerence Forum (http://www.crIorum.org/) has Iormed. From what I read, that group is
trying to come up with a standard allowing contents to be tagged and thus to bring commercial beneIit
to people with content. However, to ioin the group, you need to pay $3,000 to become an associate
member, which is Iar beyond what my budget can aIIord. I also read some interesting inIormation
Irom the DCIA.INFO group (http://dcia.inIo) about serving ads in the P2P space. As a side note, I read
on Yahoo News about 'DVD-Jon¨ being Iound innocent. DVD-Jon is the Norwegian youth who was
taken to court Ior releasing a DVD decryption algorithm.
On a more technical aspect, I managed to browse through several interesting papers about P2P
modeling and simulation. From what I read, P2P networks and applications can be modeled using
either a mathematical approach or documented using some kind oI markup language, i.e. UML Ior
instance. For example, peers can be classiIied into the Iollowing categories.
o Simple peer A peer with the basic Iunctionality oI a server and a client that is designed to represent a
single end user.
o Super peer (Rendezvous peer) - A more capable peer (more CPU power, greater bandwidth, storage space,
etc.) that is designed to be the meeting point Ior other peers.
o Micro peer A peer that is designed to operate on an embedded device, oIten with trimmed down
capabilities, or transient network connections
o Routing peer A peer that is designed to act as a router Ior P2P traIIic rather than being a provider or
consumer oI content.
o Flex-peer A peer whose Iunction can be adiusted on the Ily according to varying needs. For example, a
routing peer can be modiIied to act as a rendezvous peer or a micro peer that can temporarily act as a router
in a small BlueTooth network.
With those categories in mind, we may be able to describe activities in a P2P network using
mathematical notation. Assuming a P2P network has content providers, consumers, and routers we
might use one oI the Iollowing models:
o A simple math model could be connections ÷ m x n where m is the number oI providers and n is the
number oI consumers.
o A slightly enhanced model could be connections ÷ f(n) x n where the number oI providers can be
expressed as a Iunction oI the number oI consumers. This is because in a P2P network an endpoint is both
an inIormation provider and a consumer.
o A Iurther expanded model could be connections ÷ f(n) x g(n) x z(n) where z(n) is a Iunction taking
account oI 'noise Iiltering¨ activity at routers. Some examples oI 'noise Iiltering¨ are throttle-controls oI
pings, caches Ior Irequently used queries and responses, and cache updating rates, etc.
P2P Journal, January, 2004
18
o Still Iurther, P2P networks are not isolated. Under the Iederated P2P model, there are interIerences and
interdependencies between diIIerent P2P networks. In addition the traIIic can be expressed by the
summation Iunction f(n) x g(n) x z(n)x where maybe some kind oI interIerence Iactor when P2P
traIIic Ilow across diIIerent network boundaries.
Some studies have shown that P2P networks can be described by the Stanley Milgram s 'small world
network¨ phenomenon, a.k.a. 'six-degrees oI separation¨. In mathematical notation, such a network
topology could be described by the power law equation y ÷ bx
a,
where y is the probabilistic value Ior a
peer in a P2P network with a number oI outgoing edges x and a & b are mathematical constants.
I have Iound several rather interesting articles on the web. See below:
1. http://www.ececs.uc.edu/~miovanov/thesis/index.html
2. http://www.ececs.uc.edu/~miovanov/Research/paper.html
3. http://xenia.media.mit.edu/~jim/projects/atomic/publications/youll-thesis-
2001-dist.pdf
4. http://www.kbs.uni-hannover.de/Arbeiten/Publikationen/2002/P2P2002.pdI
5. http://www.isi.edu/nsnam/ns/
The downside to using a mathematical modeling technique Ior P2P systems is that it makes a
generalization about the system at the expense oI discounting details about individual endpoints. An
alternative method is to model the system using UML. (See Iigure below)
P2P Journal, January, 2004
19
However, the UML modeling technique also has limitations. P2P networks could potentially have
thousands, millions, or billions oI nodes, which would present a serious challenge Ior the UML
approach.
This caused me to wonder iI there could be a means to bridge the gap between those approaches. AIter
talking with some Iriends, I realized that maybe we need to design a suitable markup language and
begin the process Irom a more basic position. That markup language could be called the P2P Modeling
Language (P2PML). (The current name is only my personal preIerence.) P2PML should be expressed
using XML. XML brings several key advantages, as its data contents are structured and human
readable. Additionally, XML is extensible, allowing new tags to be introduced to suit Iuture needs.
With Iurther investigation, I also Iound that the World Wide Web consortium s (W3.org) has already
sponsored several markup language proiects, including Mathematical Markup Language (MathML),
P2P Journal, January, 2004
20
Network Markup Language (NML), and Simulation ReIerence Markup Language (SRML), etc. Some
proiects have even speciIications in version 2 state.
1. http://www.w3.org/TR/MathML2/
2. http://www.w3.org/TR/2002/NOTE-SRML-20021218/
3. http://www.omg.org/technology/documents/Iormal/xmi.htm
4. http://www.nnml.alt.ru/index.shtml
Furthermore, the Obiect Management Group (OMG) has proposed the XML Metadata Interchange
(XMI) as a vehicle to enable easy interchange oI metadata between UML, Meta Obiect Facility
(MOF), and XML language. P2PML could link those diIIerent methods and allow modeling
inIormation to be presented in both mathematical notations as well as in easy to grasp graphical
artiIacts. I have put together a little code snippet to demonstrate that purpose. (See below) The code
snippet is merely a speculation and should not be considered Iinal.
·?xml version÷"1.0" encoding÷"UTF-8"?~
·xs:schema targetNamespace÷"http://p2piournal.com/p2pml" xmlns:p2pml÷"http://p2piournal.com/p2pml"
xmlns:xs÷"http://www.w3.org/2001/XMLSchema" elementFormDeIault÷"qualiIied"
attributeFormDeIault÷"qualiIied"~
·xs:element name÷"network"~
·xs:annotation~
·xs:documentation~P2P Modeling Language·/xs:documentation~
·/xs:annotation~
·xs:complexType~
·xs:sequence~
·xs:element name÷"endpoint"~
·xs:complexType~
·xs:sequence~
·xs:element name÷"address"/~
·xs:element name÷"identiIier"/~
·xs:element name÷"activeState"/~
·/xs:sequence~
·/xs:complexType~
·/xs:element~
·xs:element name÷"role"~
·xs:complexType~
·xs:sequence~
·xs:element name÷"simplePeer"/~
·xs:element name÷"superPeer"/~
·xs:element name÷"microPeer"/~
·xs:element name÷"routingPeer"/~
·xs:element name÷"IlexPeer"/~
·/xs:sequence~
·/xs:complexType~
·/xs:element~
·/xs:sequence~
·/xs:complexType~
·/xs:element~
·/xs:schema~
I also read discussions Irom the Internet 2 group about how P2P communications have developed over
time. It seems that three primary models have been identiIied.
Pure P2P - where two arbitrary edge devices talk to each other without any central coordination. This is also
the traditional view Ior P2P networks.
P2P Journal, January, 2004
21
Hybrid P2P (P2P & server-based) - where there is a partial reliance on central coordination. Applications
such as instant messaging (IM), message board / Usenet, and Napster (a Iile-sharing application) have a
reliance on a central service Ior user association, message routing and propagation, centralized conIiguration
and storage, and directory listings.
Federated P2P - where managed P2P communications occur in the realm oI domains, Ior example, inside a
corporation or a campus inIrastructure in an educational institute. The Iederated P2P may have Ieatures such
as:
o Identity management service - based on a directory inIrastructure
o Domain membership service Peers in a domain have access to certain privileged Iunctions, such
as sending IM with embedded scripts and programs, downloading Iiles Irom peers, running iobs on
peers idle CPU cycle, editing or annotating peers document. While peers outside oI the domain only
get essential services such as browsing directory listing oI peers, sending text-based IM, etc.
o Cross-domain service The identity oI a peer Irom a Iriendly domain is veriIied: and, that peer is
given privileged service locally on temporary basis.
Additional P2P organizational schemes will evolve and appear over time. Some may depend on the
underlying network architecture, mobility requirements, and governing policies.
I hope very much that others will be interested to ioin in the exploration oI these ideas with me. I
would be very interested to hear both supporting and counter-arguments.
Much has been said. We will keep an eye out Ior new development in the P2P world and Iollow up in
the March issue oI P2PJ.
Merry Christmas and Happy New Year
Yours Truly,
Raymond Gao
March, 2004
Contents for March, 2004
Middleware to Motivate Co-operation in Peer-to-Peer
Systems
by Ben Strulo
This is a proiect discussion about the MMAPPS proiect - a Iramework to provide
incentives Ior cooperation in P2P applications beyond simple simple Iile sharing.
Tournament in P2P Networks
by David Savage
This articles discusses the mechanics and dynamics oI tournament Iormation in
P2P network, particularly about the game oI Go.
Editor's Note
by Raymond Gao
This note talks about my experience oI learning the JXTA 2.2.x platIorm and using
the JXTA programmer's guide and tutorials.
Call for Paper
Cover Image: "The Light oI My Heart", A painting by Raymond Gao, 1999, depicting the 17
miles coastline oI Monterey Bay, CaliIornia, with the lonely cypress tree standing Iirm
against the PaciIic tides.
(Additionally, we have a "call Ior the cover image" Ior upcoming issues oI P2PJ. Submit
your artwork to raygao(comcast.net. Submission does not guarantee the automatic print oI
your artwork.)
Editor-in-ChieI: Raymond Gao, raygao(comcast.net, editor(p2piournal.com
Director oI the Review Board: Sam Joseph, sam(neurogrid.com, sam(p2piournal.com
JXTA Track Editor: Daniel Brookshier, turbogeek(cluck.com
Contributing Editors: Ben Strulo, David Savage, Adnan Fida
P2P Journal is currently accepting articles Ior upcoming issues.
Copyright 2004: Unless with explicit written permission Irom P2P Journal, no part oI this iournal
may be recycled or reproduced in whole or parts.
1
12
19
27
March. 2004. P2P Journal
1
Middleware to Motivate Co-operation in Peer-to-Peer Systems
(A Proiect Discussion)
Ben Strulo
BT Exact
Adastral Park. Martlesham Heath.
Ipswich. IP5 3RE. UK
E-mail: ben.strulo(bt.com
Abstract
MMAPPS is an EU collaborative profect
developing a framework to provide incentives for
cooperation in P2P applications bevond simple file-
sharing. 1he profect has developed flexible
middleware which unifies existing and novel
approaches to provide incentives to allow
application developers access to multiple and
diverse incentive schemes. 1he middleware supports
the definition of communities of peers within which
the mechanisms allow application rules to be
checked and rewards and sanctions to be applied.
1he profect is ongoing but it has alreadv shown how
applications and accounting mechanisms can be
successfullv developed with the middleware.
1 Introduction
This article introduces some oI the key ideas
developed within the collaborative proiect
MMAPPS |1|. The proiect is working to
develop a JXTA-based middleware that is
intended to support the creation oI more
eIIicient. well Iounded. and sustainable P2P
applications. The proiect`s central approach is
to extend market management techniques to
improve cooperation between peers while
enhancing the community-oriented structure oI
P2P architectures.
Current applications have diIIiculties in
providing appropriate incentives to the peers
involved. Eor example. peers wonder why they
should contribute (at some cost to themselves)
when they can still consume without
contributing. This is the well-known 'Iree-
riding¨ problem |2|. In Iact. it seems that many
applications Iunction only on the altruistic
contributions oI a small minority oI peers with
all the other peers Iree-riding. A study oI
Gnutella |3| has shown that 70 ° oI peers were
Iree riding
1
. However. these Iile-sharing
systems still work adequately because it costs
very little Ior a peer to provide (oIten illegally)
copied Iiles whilst the value oI downloading
them is high.
Creating wider applicability Ior the P2P
approach requires inclusion oI techniques to
provide better incentives to peers. Given such
incentives. rational peers will then choose to
behave co-operatively and contribute their
resources to maximize the eIIiciency oI the
community. This will allow applications with
dramatically improved utility and robustness
and hence. we anticipate. will enable completely
new domains oI use.
The MMAPPS proiect draws upon current
economic theory and social studies (partly
conducted Irom within our proiect) to develop a
generic JXTA-based middleware that provides a
collection oI such incentive schemes suitable Ior
1
Although other studies show these peers are still
contributing by routing queries e.g. http://www-
net.cs.umass.edu/~gezihui/publication/p2pmodel.pdf
March. 2004. P2P Journal
2
supporting a wide range oI P2P applications.
The middleware will support application
developers in devising a mechanism tailored to
their own application and community. This
mechanism can use payment schemes. where
appropriate. alongside other. community-based.
accounting. reward and punishment systems.
The proiect is also developing the descriptive
and analytical tools that can be used to study the
viability and appropriateness oI such schemes.
This document is structured as Iollows. Section
2 outlines several general approaches to solving
the Iree-riding problem. and develops a general
approach pursued within the proiect. Section 3
then details a generic economic model that
identiIies the key conceptual abstractions
around which the middleware was subsequently
designed. Section 4 then describes the
middleware design itselI. and our attempts to
validate it with a novel P2P application. whilst
Section 5 summarises the proiect`s status.
2 Solution Approaches
Market pricing
It will be evident Irom the Introduction that the
core problem Iaced is the design oI a system
that provides peers with the correct incentives to
contribute to a P2P community.
The most obvious market-mechanism that might
create the right incentives. and the one
supported by a large body oI theory and
practice. is the use oI a price-based market to
co-ordinate and regulate behaviour. In such a
scenario. peers are imagined to exchange tokens
(currency) oI a value equal to their consumption
oI resources. Thus the change in the number oI
tokens that a peer holds reIlects their
consumption or contribution. One early
implementation oI such a scheme was Moio
Nation |4|. In this system. peers earned "moio"
by donating resources to the community and
spent them when consuming those resources.
Thus. peers needed to maintain a balance
between contribution and consumption. Similar
economic approaches have been suggested Ior
Grid computing |5|.
However. a central issue in these price-based
approaches is whether (and how) to regulate
prices. A completely Iree market will achieve
social optimality only in the absence oI market
Iailures` (due to the presence oI monopolies.
externalities. or asymmetric inIormation
between the peers) |6|. In practice. P2P systems
oIten exhibit all three oI these characteristics
and so some price regulation is likely to be
needed.
Such (Iree or regulated) market schemes are
oIten advocated by economists. and in many
situations have a number oI advantages. A
maior advantage in standard situations is the
degree oI decentralization that can be achieved
with prices. The only action that a central
planner has to take in a classic regulated market
is Iirstly to announce a price. and then to adiust
that price according to whether the demand
exceeds or Ialls below the supply. Under well-
understood conditions. this process leads to an
eIIicient equilibrium |7|.
1o pursue such a solution in a P2P context the
kev challenge becomes how to perform this
global regulation. since there is no global
information and no central authoritv with the
power to control the prices.
There is also the concern that (psychologically)
such explicit payment schemes can work against
the collaborative. community-Iorming nature oI
P2P.
Non price-based incentive schemes
An alternative Iorm oI incentive can be
provided by the imposition oI constraints that
relate consumption to provision. (Typically. acts
oI provision are rewarded by the ability to
consume). An example oI such a constraint
March. 2004. P2P Journal
3
might be a relation between the rate oI resource
availability and resource request actions that are
made by a peer.
Eor example. a recent version oI the Kazaa
application |8| holds an internal rating
('Participation Level'') that improves as the peer
provides Iiles Ior others. High ratings are
rewarded by other peers who give a higher
priority Ior downloading. This particular
solution. however. is rather insecure. Hacks
allowing peers to undeservedly improve their
own ratings have quickly become available. e.g.
Kazaa hack |9|. The home page Ior Kazaa hack
itselI acknowledges that "In light oI the recent
abundance oI downloaders reaching 'Supreme
Being (1000)' status. some users have decided to
hastily assume that cheats were used. and
immediately cancel their uploads." Clearly. such
simple soItware solutions are inadequate. In
other systems. stronger social mechanisms are
used to expel peers who are not living up to
their obligations. Eor example. within
DirectConnect |10| each peer connects to a hub
peer. Eile sharing is then conducted with other
peers connected to that hub. Cheating (in the
Iorm oI incorrect accounting) is generally
avoided since the owner oI that hub has
visibility oI all service transactions. and can
ensure accurate reporting. but this role cannot
easily be distributed amongst other users oI the
hub.
1he challenge with this approach in a P2P
setting is how to enforce accurate accounting of
contribution and reward in a decentralised
manner.
II this could be overcome. we anticipate that
application-speciIic constraints could be used to
restrict the behaviour oI the peers and so
inIluence their decisions thereby achieving more
eIIicient usage oI the system.
MMAPPS Market Management Approach
The MMAPPS approach to stimulating
cooperation in P2P systems builds on both the
above approaches (both regulated market prices.
and non-price based schemes). Since each
approach is likely to be suitable Ior a range oI
P2P applications. we sought to develop a
generic P2P middleware that took an inclusive
approach.
Our Iirst observation was that the previously
described two challenges (oI distributed
regulation. and distributed enIorcement oI
constraints) are in Iact equivalent and are both
Iorms oI distributed social control. Our common
solution was then to use social control Irom all
the peers in the relevant peer community to
either control prices. or to apply the constraints.
SpeciIically. this requires the concepts oI:
- Community Rules - to encapsulate social
control. and to deIine the structure oI the market
within that community. These can be used either
to regulate prices. or to directly control
participation in the community.
- A Group oI Peers (Peer Group`) as a set oI
peers choosing to operate under a particular set
oI community rules. and responsible Ior
enIorcing the rules on other community
members.
The community rules deIine how peers are
expected to behave in P2P communities. and
how they can be rewarded or punished Ior good
or poor behaviour. Such rules may reIer. Ior
example. to peer identity. group membership.
prices charged. reputation. or quality oI service.
They can. Ior example. set the maximum size oI
the group or state that members who do not
contribute must be expelled Irom the group.
Examples oI rules used in this way in the real
world are market rules oI stock exchanges.
electricity market rules. oil cartels. and
environmental regulation.
Dividing the global community into explicit
peer groups aids scalability and management.
Division oI communities into groups is used Ior
example in DirectConnect and Sun's JXTA |11|.
Shirky |12| writes about the desirability oI
groups in the general Internet and his arguments
March. 2004. P2P Journal
4
apply equally to groups in P2P systems. He
claims that successIul groups are those that have
a deIined maximum size or those that have non-
trivial barriers to entry. Eurthermore. there must
be enIorceable community norms to limit
individual Ireedoms. These can prevent the
group Irom being taken over by hostile users.
Economic Structures
Eor many P2P systems. it seems that price-
based incentive schemes are rather ill suited to
some oI the key characteristics oI P2P systems.
In particular:
the complexity and overheads associated
with implementing price mechanisms in
large. dynamic and highly distributed
P2P system
the potential impracticality oI direct
payments between peers (e.g. due to the
anonymity oI peers and the sheer
volume oI low value transactions).
Hence. we came to the view that non price-
based constraints are the preIerred market
management approach Ior simple symmetric
P2P systems oIIering relatively low cost
resources. Prices. or some other Iorm oI
monetary compensation. may be necessary in
situations where both high and low value
services are exchanged and peers do not have
balanced contributions (some peers may be
more on the provider side while other peers may
be more on the consumer side).
The question oI what set oI rules (i.e. what
economic structure) is best Ior a given
application is not a simple one and we cannot
oIIer a simple rule-oI-thumb. The MMAPPS
proiect is using validation based on experiment
and economic modelling to test our general
hypotheses and also to provide answers Ior
various speciIic classes oI application. We hope
that the resulting descriptive and analytic
Irameworks will provide suIIicient guidance to
developers seeking to create new communities
and sets oI rules. Ultimately such communities
will be validated by the marketplace. with the
ones that oIIer the most to their members
succeeding. and the weaker ones Iailing.
Community Rules and Peer Groups
One oI the main steps in the development oI a
new application is thus to deIine the rules that
the group (oI peers) will use. Our vision is that
new peer group creators can easily express these
rules and that the middleware will enIorce them
as automatically as possible.
The middleware must thereIore provide services
Ior applications to maintain inIormation on the
group oI peers who have access to it. |Note that
diIIerent groups may use similar (or even
identical) application soItware. but may have no
particular relationship to each other|. The peer
group is thus the level at which community
rules are deIined.
Developers oI a new group create rules that
embody their idea oI how the group will work.
and then the platIorm encodes (some) oI these
rules into soItware that each member oI the
group runs. The structure oI the rules should
mean that each member oI the group has an
incentive to conIorm to the rules because they
expect that the other members are doing so and
will consequently encourage or enIorce their
own correct behaviour.
DiIIerent sorts oI rules will need diIIerent sorts
oI enIorcement. Some rules can be enIorced
mechanically on a per transaction basis. while
others might need third-party checks perhaps on
a random policing basis. Still others (involving
a somewhat subiective perception oI quality.
say) might never be explicitly represented
within the service. and iust arise Irom a human
understanding between the people involved.
SpeciIic examples oI Rules that might be
applied to a Peer Group might be (when
expressed in English):
Your article will remain available only as long as you
continue to provide twice as much disk space as the
March. 2004. P2P Journal
5
article takes up and whilst you leave your machine
on.
Your next subscription payment will be reduced by
50° iI over the preceding month your average disk
space contribution exceeded 10 Mb.
Your number oI uploads must always exceed your
number oI downloads minus 5.
Your postings to a group should not include bad
language; iI a maiority oI peers Ieel you have broken
this rule you will be expelled Irom the group.
Our adoption oI peer groups requires that we
assume that peers operating in the system are
not completely anonymous. They are required to
adopt one or more un-Iorgeable identities within
the group. This is used to allow peers to prove
their membership. It also provides peers with a
unique identity against which accounts can be
kept. Peers can create new identities at any time
but there may be a signiIicant cost oI entry (or
re-entry) to the group making the change oI
identity expensive. There could also be group
entrance requirements based on stronger
assertions oI identity.
3 MMAPPS Economic Architecture
Eollowing the development oI our market-
management approach. the proiect conceived
and adopted the Economic Architecture shown
in Eigure 1 (and Iurther described in |13|). The
architecture decomposes the distributed
mechanisms that control consumption and
contribution into three conceptual layers.
Consumer Provider
Other
Peers
Social Control
(via Rules)
Accounting
and
Distribution
Service Usage
token
service
Tokens
Aggregated
Information
Peer Control Peer Control
Eigure 1: MMAPPS Economic Architecture
The Iigure shows the three layers instantiated on
three representative peers: a consumer oI a
service. the provider oI that service. and other
third-party peers. The Iigure shows what
happens within the system when the Iirst two
peers interact. one providing a service to the
other. The third peer then represents one other
peer (or in general a group oI other peers) that
may get involved in monitoring the provider and
consumer. The boxes then represent the
behaviour oI a peer enabled by the middleware.
and the arrows represent the Ilow oI
inIormation.
The Service Usage layer oI the architecture
shows a consumer peer using the services oI a
provider peer. This Iundamental use oI the
service is accompanied by the Ilow oI tokens
Irom consumer to provider to account Ior his
consumption. InIormation about the service
usage and any token transIers then Ilows into
the next layer up.
In the Accounting and Distribution layer.
distributed mechanisms keep track oI the
service provision inIormation by. Ior example.
passing it to other peers to hold. These
mechanisms then provide aggregated
inIormation to the top level. A variety oI such
mechanisms can be used interchangeably
according to tradeoIIs between eIIiciency.
security. resilience and so on.
March. 2004. P2P Journal
6
The Social Control layer holds the community
rules. In this layer. peers check the data
provided by the layer below and then perIorm
actions (such as reward and punishment) based
on community rules.
The layers are described in more detail below.
The Service Usage layer
In the Service Usage layer. the act oI service
provision is combined with Ilows oI accounting-
related inIormation such as receipts. invoices or
Iorms oI currency token. This inIormation is
represented by a token. usually signed by the
sender. The standard example is that the
consumer sends a signed receipt to the provider.
Eor the purposes oI price regulation. a signed
invoice may also Ilow Irom provider to
consumer. Eor other accounting mechanisms.
the tokens that Ilow may be deIined by a bank
and act as a currency token. The precise
protocol used Ior token exchange is deIined by
the accounting layer above.
The service provision layer is extensively
conIigurable including. Ior example. whether it
is pre-pay or post-pay (this deIines who takes
the initial risk). the nature oI the tokens
exchanged and the protocol used. and how small
the granularity oI provision should be (i.e. how
oIten to exchange tokens).
The Accounting and Distribution layer
The Accounting and Distribution layer provides
mechanisms Ior recording and aggregating
inIormation about the service usage by peers.
and Ior distributing this inIormation
appropriately. The Ilows oI accounting
inIormation Irom peer to peer can be aggregated
and delivered to those peers who need it Ior
social control purposes while preventing
individual peers Irom IalsiIying that inIormation
(e.g. to obtain unearned credit).
II tokens are used that can be directly
redeemable at a bank. then accounting can be
very simple: the provider will simply store
tokens until they can be eIIiciently redeemed.
However. it is expected that. even here. it will
be important to provide inIormation about these
exchanges to the social control layer to enable
peer group oversight. particularly Ior price
regulation but also Ior the enIorcement oI other
rules.
Thus it is expected that the accounting system
will obtain tokens Ior each exchange oI value.
Its iob now is to maintain these records so that it
can provide inIormation to peers so that they
can deduce how to act. It is here that the
MMAPPS proiect oIIers a 'toolbox¨ oI
mechanisms that achieve trustworthy
accounting and distribution oI these records.
The mechanism used in this layer needs to
match the nature oI the token exchange. to
support it and to provide appropriate
inIormation to the layer above.
The Social Control layer
Community rules are the key mechanism
operating in the Social Control layer. MMAPPS
provides developers with the tools to design
rules that are appropriate to the particular
application and peer-group that will use it.
These community rules take inIormation
obtained Irom the accounting layer and make
decisions on whether to reward or punish other
peers. It is these community rules that are the
key controlling mechanism in this social control
layer.
The tools oI reward include preIerential service
and real money while punishment can be
Iinancial. against entitlements held by the group
or. ultimately. expulsion Irom the group. based
on consensus-Iorming mechanisms such as
voting.
Classes oI Accounting Patterns
As described previously. the Accounting and
Distribution Layer is key to the MMAPPS
March. 2004. P2P Journal
7
architecture. The proiect is implementing a
number oI diIIerent accounting mechanisms Ior
this layer as part oI its middleware. These
accounting mechanisms represent one oI the
most interesting and novel aspects oI the
middleware. The intention is to provide
application developers with a wide choice oI
such mechanisms. allowing them to be Ilexible
in the construction oI their P2P systems. A
generic interIace is provided so that the
mechanisms can be changed without changing
the application.
The accounting mechanisms are discussed
below. Eirstly we present three diIIerent
methods oI storing the data as a collection oI
account transactions where no currency is used.
Then we present a number oI ways to hold the
data as a collection oI currency tokens. Einally
we discuss other Iorms oI accounting that can
be implemented as accounting patterns but with
diIIerent Iunctional properties.
1ransaction Record Based Accounts
Local accounts: The simplest accounting
mechanism is that each peer keeps a record oI
their own behaviour. This mechanism is
insecure. It gives consuming peers no incentive
to keep accurate records; this is exactly the
problem that Iaces Kazaa.
Public accounts: The public accounts
mechanism requires peers to keep complete
public accounts oI their transactions. Peers
cannot delete consumption transactions because
the corresponding provision transaction in the
provider means they are always at risk oI
discovery. Peers can regularly audit the
accounts oI other peers to discover Ialse
accounts. The mechanism allows history to be
eventually rolled up into a carried-Iorward
balance. This can be achieved by asking a group
oI peers to sign any proposed balance. Once a
balance is adequately attested (say. by a
minimum number oI other peers) it can be
added to the account and the history deleted.
A similar. but less general. system is described
by Wallach |14|.
Third party account holders: The third party
account holders mechanism provides a remedy
Ior the insecurity oI local recording oI the peer`s
account. Eor example. iI a Distributed Hash
Table such as Pastry |15| is used. the peer
addressing mechanism can designate one or
more other peers to hold the account. The
provider sends each signed receipt to its account
holders and then Irom them on to the account
holders Ior the consumer. The account holders
need to hold these records only Ior a short time
at most and then they can roll them up into the
aggregated balance.
Currencv 1oken-Based Accounts
Instead oI keeping explicit records oI all
transactions. a mechanism like digital cash can
be used in which each peer holds an account
represented by a number oI cryptographic
tokens that they cannot Iorge. The exchange oI
these tokens is managed by the lower layer oI
the architecture. The accounting layer can
arrange Ior the issue and redemption oI tokens
when necessary.
Cryptographic tokens need to be issued by
someone. Eurthermore. to control the possibility
oI a peer double-spending a single token. they
must eventually return to the issuer (in the
absence oI trusted hardware at the peer). The
proiect has identiIied three mechanisms based
on the identity oI that issuer.
Tokens issued by an external bank: In the
usual digital cash case. the issuer is a trusted
bank external to the peer group. However. the
cost oI using such a bank is not negligible.
Eurthermore. the use oI an external bank
imposes restrictions on the peers (e.g. that they
use a common banking system) that are
somewhat contrary to the co-operative and ad-
hoc nature oI P2P applications.
March. 2004. P2P Journal
8
Tokens issued by an internal distributed
bank: It is also possible Ior a sub-group oI the
peers to create a distributed bank that can mint
its own currency. Threshold cryptography |16|
can be used to allow the whole sub-group to
create tokens together but to prevent any
smaller sub-group doing the same. However. the
necessary intra-bank communications seems to
be a heavy overhead. A novel version oI this
was one oI the Iirst patterns to be implemented
within the MMAPPS proiect |17|.
Use of Peer currency: A particularly appealing
approach is to allow each peer to mint their own
currency. This means that providing peers will
rapidly collect coins Irom a variety oI banks. To
control double spending. peers will need to
regularly redeem coins at the issuer. However.
the issuer may have no service to provide the
peers to whom they are in debt. They may be
able to redeem their own coins against coins
Irom another issuer. But these will also need to
return Ior checking against double spending (see
|18|).
Other Accounting Patterns
Other mechanisms have been suggested to allow
peers to gather group consensus inIormation
about each other. such as reputation systems
based on gossip or query and also voting
mechanisms. Such mechanisms are Iormally
similar to these accounting mechanisms. though
they may not be based directly on the
accounting tokens in quite the same way. The
proiect plans to provide some oI these
mechanisms Ior the use oI the rules in the layer
above.
4 MMAPPS Middleware
Design SpeciIication
The MMAPPS Middleware SpeciIication (see
Eigure 2) describes a soItware design Ior the
Economic Architecture that supports P2P
application developers in adding powerIul
incentive mechanisms into their applications
with the minimum oI diIIiculty.
Application
Accounting & Charging
Negotiation Search
GroupMgt
lmplementation Platform (eg JXTA)
Local Resources
Peer X
Core Functionality
Middleware
code
Application
code
Eigure 2: Outline Middleware SpeciIication
The core oI the architecture is represented in
this speciIication by simply two modules within
the middleware:
The Accounting & Charging module
encapsulates both the Accounting and
Distribution (middle) layer oI the Economic
Architecture (see Eigure 1). together with the
token-exchange part oI the Service Usage
(lower) layer.
The Rules & Policies module Iully encapsulates
the Social Control layer oI that architecture (the
community rules) but also includes local rules.
policies`. stipulated by that peer. Usually we
expect a peer to speciIy its policies to be
consistent with the community rules
2
(e.g. the
community rules may allow peers to
discriminate over who they provide services to.
and so a policy may express that
discrimination).
Three Iurther middleware modules then provide
the essential supporting inIrastructure within the
middleware:
2
Peers are Iree to implement policies that conIlict with the
community rules but they then risk being observed by other
peers in the community and so being subiect to the
punishments described in the community rules.
March. 2004. P2P Journal
9
The Group Management module explicitly
supports the key MMAPPS concept oI a peer
group (i.e. the Iact that peers operate within
well-deIined communities). When a particular
peer ioins. leaves. or is evicted Irom a Peer
Group. this change in membership status is
managed through this module.
The Search module supports mechanisms that
allow the discovery oI the services oIIered by
other (remote) peers i.e. the process oI service
discovery.
The Negotiation module encapsulates the
Iunctionality that supports the bilateral
negotiation oI service provision contracts
between peers. This may include negotiation oI
price. Quality oI Service (QoS). payment
periods. and pre- or post-payment. In the Iuture.
this could also include multi-party negotiation
(e.g. support Ior auctions).
Einally. the speciIication shows (possibly
multiple) Service modules. and the Application
module code itselI:
The Service module essentially represents the
service(s) provided by one peer to another. and
whose activity is accounted Ior by the
Accounting & Charging module
3
. |Like the
Rules & Policies module. the Service module is
somewhat complex in that it is partly generic
middleware code. and partly application-
speciIic customisation this is why it is
depicted as spanning the
application/middleware interIace|.
The Application module then contains all oI the
residual application-speciIic code including
that required in order Ior the user to interact
with and control the middleware and services.
3
In MMAPPS. only the activities oI the Service module can be
accounted Ior. We assume that the activity oI (say) searching
(perIormed by the Search module) is a trivial overhead in
comparison to the utility oIIered by participation in the
community.
Our current implementation oI this design is
based upon JXTA and Java. We have Iound that
JXTA already supports our requirements Ior the
Group Management and Search modules. and so
the MMAPPS middleware can be regarded as a
being a number oI module extensions to the
basic JXTA toolkit.
Design Validation
There are many aspects oI MMAPPS that need
to be validated. some oI which are Iundamental.
and some oI which are
supplementary/peripheral. and each oI which
calls Ior a diIIerent validation strategy. Eor
example. the Iundamental economic robustness
oI rules is being validated directly through our
own theoretical modelling work |19|; whilst the
validity oI our vision oI a highly-abstract
(conIiguration-only) rules module is likely to
remain a long-term. multi-proiect obiective.
Current validation activity Iocuses on assessing
the degree to which the middleware does indeed
aid the development oI P2P applications. This is
principally through our use oI the middleware to
build several compelling. and diverse P2P
applications.
Having Iocused initially on File Sharing (the
prototypical P2P application). and implemented
this with two diIIerent accounting patterns
(record-based and token-based). we have
subsequently developed a more novel P2P
application based upon reciprocity in network
access amongst a group oI collaborating WLAN
administrators.
The P2P Wireless Network Confederation
(P2PWNC) |20. 21| is a community oI WLAN
administrative domains that oIIer network
access (e.g. Internet connectivity) to each other's
registered users. The great beneIit oI near-
ubiquitous access that these roaming users could
enioy compensates Ior their domain's cost oI
providing access to visitors. Existing roaming
March. 2004. P2P Journal
10
schemes utilize central authorities or bilateral
contracts to control the parties' behaviour. In
contrast. a P2PWNC Iorms a P2P community in
which participating domains are autonomous
entities and they make independent decisions
concerning the amount oI resources (access
bandwidth) they contribute. As a result.
similarly to existing P2P systems. a P2PWNC
would ordinarily suIIer Irom Iree-riding iI no
incentive mechanisms exist to ensure that
domains oIIer the amount oI resources that is
economically iustiIied.
This application has been successIully
prototyped using the MMAPPS middleware
with the rules written to require reciprocity
amongst the peers in order to regulate (and
incentivise) an individual administrator`s access
provision policy.
Developing these applications has generally
validated our application development paradigm
(though highlighted a Iew residual issues). and
also demonstrated the inter-changeability oI the
accounting patterns.
5 Summary
This article has described a new and generic
economic architecture Ior P2P systems and has
proposed a JXTA-based middleware designed to
support it.
The Ilexibility oI the middleware is achieved by
the deIinition oI a generic accounting
abstraction. which separates rules Irom
accounting. The rules deIine the economy oI the
community while the accounting provides the
inIormation necessary to check and enIorce the
rules. This structure can support many existing
approaches to providing incentives. but has also
stimulated the development oI new approaches.
Enabling new and improved incentive schemes
is a vital step towards expanding the application
oI P2P into new domains.
The middleware remains under development but
it has already successIully supported two
distinct application scenarios and two
accounting patterns.
6 Acknowledgements
This work Iorms part oI the output oI the
MMAPPS proiect. which is part-Iunded by the
EU under the EiIth Eramework contract IST-
2001-34201. The partners within the MMAPPS
proiect are: BT Research (UK) (Coordinator).
Athens University oI Economics and Business
(Greece). Eidgenössische Technische
Hochschule (Switzerland). Darmstadt
University oI Technology (Germany).
Mysterian (UK). Telekom Austria (Austria) and
University oI Lancaster (UK).
The author grateIully acknowledges the
contributions oI the other partners to this
document. However. the views represented in
this paper. and any mistakes therein. are the
responsibility oI the author. and the document
may not reIlect the views oI the proiect.
Author
Ben Strulo has worked in IT since 1981 and IT
research since starting his MSc in 1989. He
obtained his PhD in Computer Science
(speciIically on the semantics oI Process
Algebras) in 1993 Irom Imperial College. He
now works Ior BT Exact. BT's research.
technology and IT operations business
He currently leads a research team Iocused on
applying the Internet end-to-end design
principles to communications service
implementation. and is Technical Director oI the
MMAPPS EiIth Eramework proiect.
March. 2004. P2P Journal
11
8. References
|1| See http://www.mmapps.org.
|2| G. Marwell and R. Ames. 'Experiments in the
provision oI public goods: I. resources. interest. group
size. and the Iree-rider problem¨. American Journal of
Sociologv. no. 84. 1979.
|3| E. Adar and B. Huberman. 'Eree Riding on
Gnutella¨. First Mondav. vol. 5. October 2000.
|4| J. McCoy. 'Moio Nation Responds¨.
http://www.openp2p.com/pub/a/p2p/2001/01/11/moio.ht
ml.
|5| R. Buyya. H. Stockinger. J. Giddy. and D.
Abrams. 'Economic models Ior management oI resources
in grid computing". in Commercial Applications for
High-Performance Computing. 2001.
|6|
http://www.worldbank.org/wbi/sdenveconomics/eep/docs
/reading/MarketEailuresPolicyEailures.pdI
|7| Hal R. Varian. 'Microeconomic Analvsis¨. W. W.
Norton and Company. 1978.
|8| Kazaa. http://www.kazaa.com/
|9| Kazaa Hack. http://kazaahack.250x.com/
|10| NeoModus - Home oI DirectConnect.
http://www.neo-modus.com/
|11| Proiect JXTA. http://www.ixta.org/
|12| C. Shirky. 'Social SoItware and the Politics oI
Groups¨. http://www.shirky.com/writings/group
politics.html/
|13| Ben Strulo. Alan Smith. JeII Earr. An
Architecture Ior Peer-to-Peer Economies. Third IEEE
International ConIerence on Peer-to-Peer Computing
(P2P 2003). Linkoping. Sweden. 1-3 September 2003.
|14| D. Wallach. 'A survey oI Peer-to-Peer Security
Issues¨. International Symposium on SoItware Security.
Tokyo. Japan. November 2002.
|15| A. Rowstron. and P. Druschel. 'Pastry: Scalable.
distributed obiect location and routing Ior large-scale
peer-to-peer systems¨. in IEIP/ACM International
ConIerence on Distributed Systems PlatIorms
(Middleware). pp. 329{350. 2001.
|16| Y. Desmedt and Y. Erankel. 'Threshold
cryptosystems¨. In G. Brassard. editor. Advances in
Crvptologv. Crypto '89 (Lecture Notes in Computer
Science 435). pages 307{315. Santa Barbara. CaliIornia.
U.S.A.. August 1990. Springer-Verlag.
|17| David Hausheer. Nicolas C. Liebau. Andreas
Mauthe. RalI Steinmetz. Burkhard Stiller: Token-based
Accounting and Distributed Pricing to Introduce Market
Mechanisms in a Peer-to-Peer Eile Sharing Scenario. In
Proc. 3rd IEEE International ConIerence on Peer-to-Peer
Computing. Linkoping. Sweden. September 1-3. 2003.
|18| B. Yang and H. Garcia-Molina. PPay:
Micropayments Ior Peer-to-Peer Systems. In Proc. 10th
ACM ConIerence on Computer and Communications
Security (CCS). Oct 2003.
|19| P. Antoniadis. C. Courcoubetis and R. Mason.
'Comparing Economic Incentives in Peer-to-Peer
Networks¨. to appear in Special Issue on Internet
Economics. Computer Networks.
|20| P. Antoniadis. C. Courcoubetis. E. EIstathiou. G.
Polyzos. and B. Strulo. Peer-to-Peer Wireless LAN
Consortia: Modelling and Architecture. (pdI - 170KB) -
Third IEEE International ConIerence on Peer-to-Peer
Computing (P2P 2003). Linkoping. Sweden. 1-3
September 2003.
|21| E. EIstathiou and G. Polyzos. A Peer-to-Peer
Approach to Wireless LAN Roaming (pdI - 248KB). The
Eirst ACM International Workshop on Wireless Mobile
Applications and Services on WLAN Hotspots (WMASH
2003). San Diego. CaliIornia. USA. September. 2003.
March. 2004. P2P Journal
12
Tournaments in P2P Networks
David Savage
Morgan Spenser Consulting Ltd PO Box 26973. SE21 8WU. London. UK
Phone: ¹44(0) 20 8670 2379
Email: dave(morganspenserconsulting.com
Abstract
1his paper discusses the mechanics and dvnamics of
tournament formation in P2P networks. It provides a
detailed discussion of an implementation of a tournament
using the game of Go based on JX1A P2P networking.
1 Introduction
The online dictionary. dictionary.com. |1|
provides the Iollowing deIinitions oI a
tournament:
A series of contests in which a number of
contestants compete and the one that
prevails through the final round or that
finishes with the best record is declared the
winner
and
A sporting competition in which contestants
plav a series of games to decide the winner
This paper will thereIore deIine a tournament
using three criteria. Eirstly that a game must exist
that can be repeatedly played. Secondly. that a
group oI players must exist that are capable oI
taking part in the tournament. Einally that there
must exist some Iorm oI ranking system which
can diIIerentiate player`s abilities to play the
game.
Tournaments can be Iound in virtually every
Iorm oI human interaction imaginable; it oIten
iust depends on how one chooses to view the
system as to whether the tournament is visible.
The most obvious examples oI tournaments are
Iound in sports and entertainment endeavours
Irom the Super Bowl to 'The Weakest Link¨.
However. tournaments can also be Iound in such
places as Iinancial and engineering systems. Eree
market economies are a perIect example oI a
tournament system. Organisations such as NASA
also employ tournament mechanics in saIety
systems when they build multiple
implementations oI soItware simulations and run
each in parallel. This practice highlights
discrepancies in algorithms and is a perIect
example oI when it is not the winning but the
taking part in a tournament that counts.
P2P networking |2| is both a hot topic in
computer science today and paradoxically a
technology that has existed since Alexander
Graham Bell Iirst designed the telephone. The
term describes a set oI systems that Iorm
decentralized networks. This means that there is
no central point managing content or providing a
given service. Content and services are spread
out across the network and each node in the
system is directly connected to only a small
percentage oI the total number oI other nodes.
Jovanovic etal |3| have shown that pure P2P
networks are governed by the so called 'Small
World Phenomenon¨ |4|. While each individual
node may only be connected to a small
percentage oI the whole network. the overall
connectivity oI the system is high with only a
Iew degrees oI separation between any two
nodes.
P2P networking has aIIected many areas oI the
world today Irom: the explosive growth oI so
called 'Iile sharing¨ systems including Napster
March. 2004. P2P Journal
13
|5|. Gnutella |6| and Ereenet |7|; the increased
use oI instant messaging systems such as MSN
Messenger |8|. AOL Instant Messenger |9| and
IRC |10| in both home and business
environments; and in the world oI scientiIic
research with proiects such as seti(home |11|
and compute against cancer |12|. However. one
area where the technology has yet to take hold is
that oI gaming. This is beginning to change.
though. with the publication oI papers such as
those by Knutson. B.. Lu. H etal |13| and Saddik.
A. and DuIour. A |14|. These papers discuss the
applicability oI P2P networking to multiplayer
gaming environments. This paper and the proiect
underlying it are extensions oI each oI these
areas oI work and also cover new areas oI
interest.
SpeciIically. this paper will discuss the design
and implementation oI a tournament built using
JXTA P2P networking technology |15| to allow
players to meet and play the game oI Go |16|.
The implementation builds on the work oI
Saddik and DuIour by providing several oI the
Ieatures they discuss as lacking in their
application. such as keepalive and resend. Also.
as this proiect has been implemented later in the
liIe time oI JXTA. it has been possible to take
advantage oI improvements in the core JXTA
reIerence implementation. This has meant that
the application has not had to deal with problems
such as message corruption and Irequent dropped
connections mentioned in |14| and has led to a
more reliable overall solution.
This paper relates to the work oI Knuttson etal in
their discussion oI managing availability and
security in multiplayer environments. Whilst
Knuttson etal deal with so called persistent
worlds (examples oI which are Iound in games
such as Ultima Online |17| and Everquest|18|).
this paper looks at the problems associated with
tournaments in their most general sense.
The application. source code and Iurther
documentation Ior this proiect may be Iound at
the Go P2P website |19|.
2 A P2P Go Tournament
Go is a board game between two players which
originated in China and has a recorded history oI
over 3000 years. The western name comes Irom
the Japanese word Ior the game 'Igo¨ which
means 'surrounding board game¨. The game is a
turn based system where each player places
single pieces on a board similar to the game oI
draughts. There are relatively Iew rules. but this
simplicity belies the complexity oI the game`s
underlying dynamics.
There were several reasons behind the decision
to use the game oI Go in this implementation oI a
P2P tournament.
Eirstly. this type oI game lends itselI well to P2P
systems. This is because the overall bandwidth
between players is low. This is important as
nodes in P2P networks are. in general. limited in
their capacity oI both network and computational
resources.
Secondly. there is a large community oI people
in the world who make use oI online Go
applications. Examples oI these applications
include GnuGo |20| and Jago |21|. There is.
thereIore. already a pre-existing audience Ior this
technology.
Lastly. on a more subiective level. the game
shares many oI the group theory properties oI
P2P networks. This makes it a very satisIying
problem to solve as there is symmetry in both the
network and game layers.
2.1 Implementation
The tournament is implemented using the Java
reIerence implementation oI the JXTA protocol
layer. JXTA technology was chosen Ior several
reasons.
Eirstly. it provides many useIul Ieatures at the
network layer |23| which are applicable to the
application logic oI a tournament Iramework.
This greatly reduces the complexity oI logic
required to bind the two layers and so reduces
development time. The mapping between
March. 2004. P2P Journal
14
application logic and the JXTA networking is
shown in Table 1.
Secondly. there is already a large community oI
developers and businesses involved in JXTA
communications technology. This provides
another pre-existing audience which would be
available to play in the completed tournament.
Einally. the technology is a Iamiliar one to the
author and so minimum eIIort was required in
terms oI learning new programming languages
and methodologies.
The application implements tournaments and
games as peer groups within the JXTA net peer
group. Every tournament and game is assigned a
unique I.D. based on the underlying peer group
Ior that entity. Players are also assigned unique
I.D. s generated Irom their application peer I.D.
s. This design allows many tournaments. games
and peers to exist simultaneously in the network
and to be diIIerentiated and discovered.
Tournament 3XTA
Player Peer
Tournament Peer Group
Game Peer Group
Communication Pipe
Integrity Security/
Membership
Table 1 Correspondence of tournament functions to JXTA
networking
Eigure 1 shows the current organisation oI
players and peer groups in this application. A
player is represented in tournaments and games
by a set oI adapters that pass events to and Irom
the network layer using pipes.
Figure 1 Tournament and game groups with player
projections
However the implementation also had to
overcome several key issues related to JXTA
networking speciIically and network
programming in general.
Eirstly. it had to overcome the Iact that the core
JXTA protocols provide no guarantees with
respect to message ordering and delivery
reliability. Message ordering is extremely
important in the case oI a game oI Go where the
order in which moves are received can have
drastic eIIects on the overall game environment.
ThereIore. it was important Ior the application to
develop a mechanism to handle this.
Secondly. the implementation had to deal with
the possibility oI high latency and dropped
connections.
In order to overcome these problems. the
implementation provides a network
communications layer that handles converting
player events and network events in a predictable
way. To achieve this it Iirstly uses an XML
based protocol 'ixgo¨ developed speciIically
Ior this application |19|. Jxgo packets are sent
between players using JXTA 2.2 unicast
bidirectional pipes.
The application uses a system based on PAR
(Positive Acknowledge and Retransmision)
similar to that Iound in the TCP networking |22|.
This ensures that packets are delivered. Irom the
application layer oI one peer to another. in the
correct order. This system is one oI the simplest
packet sequencing systems available. As such. it
March. 2004. P2P Journal
15
is less eIIicient with regard to network utilisation
than other schemas. including simple windowing
systems. However. this ineIIiciency does not
Iorm a signiIicant problem in this application
environment as the Irequency oI messaging
generation is slow relative to the overall response
time oI the underlying network.
The network layer also utilises a 'keep alive¨
system in the Iorm oI a timed ping-ack check
that allows a player to become aware iI a remote
player is no longer accessible on the network.
However. even with these saIe-guards in place
the connection to the remote player may still be
lost. Assuming a reconnection can be remade it
is still possible to restart the game assuming each
player leaves the application running. This is
achieved by the game being interrupted. which
prevents the local player Irom making any more
moves until the remote player manages to
reconnect. A Iuture extension will store the game
state locally in order that a game may be
reinitialized even over an application restart.
In the case oI a disconnection the application
currently drops any pending packets Ior the
remote player in order to conserve resources.
However. this can lead to a player`s move not
being transmitted iI the remote player Iails to
receive a move beIore disconnecting. To
counteract this problem. the application requests
the previous move Irom a player iI they have not
made a move in a conIigurable time period. This
ensures that even iI a move is lost due to
disconnection. the game state may still be kept
up-to-date.
2.2 Tournament groups
When new players ioin the network they may
ioin either an existing tournament or create a
new tournament. When a player ioins a
tournament the application undertakes several
tasks.
Eirstly. it publishes the tournament peer group
advertisement into the parent net peer group.
This is run as a repeated background task which
executes as long as the player is a member oI the
tournament. This renews the advertisement`s
lease in the JXTA network cache managers;
which would otherwise discard the advertisement
aIter it has passed its maximum validity period.
As this task is run by all peers that connect to the
tournament it allows the tournament`s liIetime to
be disconnected Irom the liIetime oI any
individual player in the tournament. The
tournament will continue to exist in the network
Ior as long as any players are connected.
Secondly. the application becomes a rendezvous
peer Ior the tournament group. helping to ensure
that tournament groups are well connected and
that players can easily Iind and communicate
with other players in their tournament group.
Thirdly. the application publishes a player
advertisement into the tournament group which
details aspects such as the player`s name.
preIerred game level and an advertisement Ior a
JXTA server pipe. which is used to interchange
ixgo packets. Again advertisement is renewed
using a background task Ior as long as the player
is connected to the tournament.
Einally. the application starts several other
background tasks to discover other players
advertisements in the tournament and also game
groups associated with the tournament.
When the application discovers a new player
advertisement in the tournament group it
attempts to bind to the remote player`s
communications pipe. II this is successIul the
new player is displayed to the local player and
the local player may then send chat messages
using a chat window associated with the
tournament and issue game challenges to the
remote players.
2.3 Challenge negotiations
When starting a game the application undertakes
a negotiation between each player. In the current
implementation this negotiation is initiated by
one player challenging another player to a game.
However. in Iuture implementations this logic
March. 2004. P2P Journal
16
may be initialised by human or machine
tournament managers. Eor example in the case oI
a league or cup systems the choice oI game
players is made by the underlying logic oI the
tournament itselI.
At the point oI challenge the challenging player
is able to speciIy the level oI game they would
like to play. This inIormation is sent in a
challenge request event to the player who has
been challenged. Upon receiving the request. the
application displays a message dialogue to the
challenged player who may then either accept or
reiect the challenge. This inIormation is then
passed back to the challenger as a challenge
response event.
The application currently automatically reiects a
challenge on behalI oI a player iI they are
already playing a game with another player this
is both to simpliIy the user experience. to
conserve application resources Irom having to
maintain multiple game sessions and
communications channels. and to simpliIy the
implementation code.
2.4 Game groups
II a challenge is successIul a new peer group is
set up Ior the game as a child oI the net peer
group. It was initially planned to have these
game groups as children oI the associated
tournament group. However. this has currently
proved to have perIormance issues with respect
to discovery times Ior players within these game
groups and so has been dropped in Iavour oI
game groups which are children oI the net peer
group.
Two possibilities have been identiIied Ior this
latency but as yet the deIinite cause has not been
conclusively demonstrated. This issue. thereIore.
Iorms an area Ior Iuture investigation. The Iirst
possibility revolves around the small number oI
peers in current tournament groups. This may be
adversely aIIecting the ability oI discovery
services to Iunction eIIiciently in sub-groups and
so may disappear in larger groups. The second
possibility revolves around a bug in the
underlying JXTA discovery services.
Once the new group has been created each player
ioins the game group. In order to remove the
issue oI players deciding upon their colour. it
was decided to adopt a convention that the
challenging player will always become the white
player and the challenged player will become the
black player. Under the rules oI Go this ensures
that the challenged player always gets the Iirst
move.
Joining a game group causes a similar set oI
actions as when ioining a tournament group. The
application undertakes a repeating task to publish
the game peer group advertisement into parent
group the net peer group in the current
implementation. The player`s peer becomes a
rendezvous peer Ior that game group. The
application publishes an advertisement
containing a game speciIic player advertisement
into that game peer group. This new
advertisement details the player`s colour and
provides a new pipe advertisement Ior
communications within this game group. Einally
the application starts a background task to
discover player advertisements in the game peer
group.
Each player then waits Ior the other player to be
discovered in the game peer group and Ior their
communications pipes to be successIully
connected. Once each player has ioined the game
the game then starts. Each player`s moves are
communicated to the opposing player using their
communications pipes and they are also able to
converse using a chat window associated the
game itselI.
2.5 Winners and Losers
An important aspect oI tournament systems is the
ability to measure a player`s ability to undertake
a game. In the case oI Go this scoring can be
achieved using one oI two main systems. either
Chinese or Japanese rules. Whilst these rules are
ostensibly the same there are a Iew subtleties
March. 2004. P2P Journal
17
which aIIect the overall score achieved by each
player. In both situations. though. the player with
the highest score is deemed the winner. Based on
the number oI wins or losses a player achieves
this is translated in the game oI Go into a grade.
The diIIerence in grade between two players is
then translated into a handicap. The handicap
score allows the lesser player to place a number
oI stones. equal to the handicap score. on the
board Iirst -so giving them a tactical advantage at
the start oI a game. This handicap system allows
players oI diIIerent ranks to none the less play
balanced games with each other. This
inclusiveness is one oI the maior reasons why the
game in general is so popular.
2.6 Integrity
There are several problems associated with
integrity in this system.
Eirstly. that oI reliability which ensures that each
player has the same view oI a game or
tournament. The implementation deals with this
problem in terms oI a games liIe-cycle as
detailed above. However. in the Iuture iI the
application is to implement reIereed games and
tournaments it will be important to handle issues
such as two-phase commits to ensure data is
managed between three or more remote parties.
Secondly there is the issue oI inIormation
degradation. This occurs when a player is
disconnected Irom the network Ior any prolonged
period oI time. On reconnection the inIormation
stored on that peer must be synchronized with
that in the rest oI the peer group. However. this
problem is less than trivial to solve in ad-hoc
P2P networks such as JXTA. In the current
implementation there is very little application
inIormation stored locally so this problem does
not arise. Going Iorward it will be an important
issue to take account oI.
Thirdly. there is the problem oI trust |25| which
also plays a part in the previous problem and
aIIects the integrity oI a tournament. Trust is
important in aspects such as ensuring that a
player has the correct grade and does not cheat to
gain points in the tournament. It is also important
in ensuring that a reIeree gives Iair handling to
all players in a tournament.
Eourthly. there is the problem oI advertisement
latency. An example where this can occur is that
oI handling handicaps in Go games. This
inIormation may be advertised by a player.
However. any mismatch between a local and
remote view oI this inIormation can cause
several problems. Namely. players taking
incorrect numbers oI handicap moves at the start
oI a match or players challenging based on
outdated inIormation. This may be remedied by a
player making a direct request to another player
to update grade inIormation at the time oI game
initiation.
3 Conclusion
This paper has discussed the implementation oI a
Go tournament systems in P2P networks using
JXTA networking technology.
It has been shown that the JXTA protocols
provide several core tools such as the notion oI
peers. groups and pipes which make it especially
relevant to development oI a tournament system.
However. to successIully build a basic Go
tournament it has also been necessary to
overcome a number oI technical challenges.
Namely. to address the unreliability oI
communications channels in JXTA networking
and to deal with network latency and
disconnections.
As Ior Iuture work. there are several key areas
which need to be implemented in order to Iorm a
Iully Iledged p2p tournament system. These
include managing trust relationships and
game/tournament state inIormation.
References
1. Dictionary.com
http://www.dictionary.com
March. 2004. P2P Journal
18
2. Shirky. C (2000) What Is P2P.And
What Isn`t
http://www.openp2p.com/pub/a/p2p/2000
/11/24/shirky1-whatisp2p.html
3. Jovanovic. M. Annexstein. E. Berman. K.
Modelling Peer-To-Peer Network
Topologies Through 'Small World¨
Models and Power Laws
http://www.ececs.uc.edu/~miovanov/Res
earch/telIor.pdI
4. Klienberg. J. (1998) The Small World
Phenomenon: An Algorithmic
Perspective
http://www.cs.cornell.edu/home/kleinber/
swn.d/swn.html
5. Napster http://www.napster.com
6. Gnutella http://www.gnutella.com
7. Ereenet http://Ireenet.sourceIorge.net
8. MSN Messenger
http://messenger.msn.com
9. AOL Instant Messenger
http://www.aim.com
10. IRC http://www.irchelp.org
11. SETI(Home
http://setiathome.ssl.berkeley.edu
12. Compute Against Cancer
http://www.computeagainstcancer.org
13. Knutson. B.. Lu. H. Xu. W. Hopkins. B.
Peer-to-Peer Support Ior Massively
Multiplayer Games
http://www.cis.upenn.edu/~hhl/Papers/inI
ocom04.pdI
14. Saddik. A.. DuIour. A. Peer-to-Peer
Suitability Ior Collaborative Multiplayer
Games
http://www.site.uottawa.ca/~elsaddik/abe
dweb/publications/peer2peer.pdI
15. Proiect JXTA http://www.ixta.org
16. Sensei`s Library http://senseis.xmp.net
17. Ultima Online http://www.uo.com
18. EverQuest
http://everquest.station.sony.com
19. Go P2P http://go.ixta.org
20. GnuGo
http://www.gnu.org/soItware/gnugo/gnug
o.html
21. Jago http://www.rene-grothmann.de/iago
22. Transmission Control Protocol REC
http://www.Iaqs.org/rIcs/rIc793.html
23. Traversat. B. Arora. A. Abdelaziz. M.
etal. (2003) Proiect JXTA 2.0 Super-Peer
Virtual Network
http://www.ixta.org/proiect/www/docs/J
XTA2.0protocols1.pdI
24. Sun Microsystems (2001) Security and
Proiect JXTA
http://www.ixta.org/proiect/www/docs/Se
curityJXTA.PDE
25. Chen. R. Yeager. W. Sun Microsystems
http://www.ixta.org/docs/trust.pdI
Author
David Savage is managing director oI Morgan
Spenser Consulting Ltd. He lives in London. UK
and has worked Ior a number oI years in the
Iinance and telecoms industries designing and
building systems which utilise distributed
computing technology. Prior to this he studied
Physics at CardiII University where he gained a
1
st
Class Honours MPhys and became a Iinalist
Ior the UK`s Science and Engineering Student oI
the Year competition 1999 Ior his Iinal year
proiect on quantum scale wires.
March. 2004. P2P Journal
19
Editor`s Note for March, 2004 Issue
Raymond Gao
P2P Journal ( http://p2piournal.com )
Phone: 972-530-4562
e-mail: raygao(comcast.net
1 Introduction
During the last two months. I had some Iree time
at hand. So. I decided to catch up with the most
current JXTA release. It has been a while since I
last read the API speciIications. so I dug out my
JXTA book. and downloaded the associated
example source code Irom the web. However.
there have been numerous changes between
JXTA 1.0 and 2.x platIorms. I could only get one
program Irom that book compiled without
making modiIications. I am using JXTA 2.2.x
platIorm.
Now. I have an interesting tale oI my reIresher
course with JXTA technology.
2 Changing APIs
Between JXTA 1.0 platIorms and 2.0 platIorms.
there were many signiIicant changes. e.g. to
enhance system perIormance. to keep up with
J2SE evolution. and to expand Iunctionalities.
Those changes are essential. as the 2.0 platIorm
achieved signiIicant perIormance improvement
and added many important capabilities over the
1.0 platIorm. However. those changes also
caused a breakage in backward compatibility.
Programs written Ior the JXTA 1.0 platIorm
probably need to be modiIied in order to work on
the JXTA 2.0 environment. Moreover. with the
upcoming release oI JXTA 2.2.1 branch. a.k.a.
'Churassco¨. it is introducing additional
complexity. e.g. backward compatibility issues.
(A list oI diIIerences between JXTA 1.0 and 2.0
is attached at the end oI this note.)
3 Example from 3XTA 2.0 Programmer`s
Guide
Because oI those changes. I decided that it would
be a worthwhile eIIort to learn about the JXTA
2.2 platIorm. So. I downloaded the 'Proiect
JXTA 2.0: Java
TM
Programmer`s Guide¨ and
companion tutorial Iiles Irom JXTA.ORG`s
website.
o http://www.ixta.org/docs/JxtaProgGuide_
v2.pdI
o http://www.ixta.org/docs//ProgGuideExa
mples_2.0.zip
There are a total oI 9 example programs in the
programmer`s guide. Irom the simplest
HelloWorld to the more complex - JXTA Bi-
directional pipe and creating secure peer groups.
3.1 Network configuration
The Iirst Iew examples are clear and
straightIorward. I compiled and ran them without
any hitch. To compile the example applications.
one needs to set the correct 'CLASSPATH¨
variable. The Iollowing code snippet shows the
commands that I used Ior my Windows OS
environment.
Code 1 Setting the classpath variable for JXTA
set ixta_dir÷C:\Users\p2pi\ixta\ixta_2_2_1
set
classpath÷°classpath°;°ixta_dir°\ixtaptls.iar;°ixta_dir°
\bcprov-idk14-122.iar;°ixta_dir°\cryptix-
asn1.iar;°ixta_dir°\cryptix32.iar;°ixta_dir°\iavax.servlet
.iar;°ixta_dir°\ixta.iar;°ixta_dir°\ixtasecurity.iar;°ixta_
dir°\ixtashell.iar;°ixta_dir°\log4i.iar;°ixta_dir°\org.mor
tbay.ietty.iar;.
March. 2004. P2P Journal
20
Examples that deal with passing messages
between two peers are a bit more complex. I
wanted to run both the server and the client
program Irom my laptop. This requires running
the client and the server on diIIerent ports. I
decided that the server would run on port # 9700
and the client on port # 9704.
Setting port numbers involves using the 'JXTA
ConIigurator¨ which is the GUI interIace Ior
setting the .3XTA directory and subordinate Iiles.
The JXTA conIiguration inIormation is stored in
the Iile N\XE4PEXJSVQ'SRJMK. while
security inIormation (username and password) is
stored in the N\XETWI subdirectory. The
next time the application runs. this inIormation is
used to conIigure your peer. To re-run the auto-
conIiguration tool. you need to create a Iile
named VIGSRJ in the N\XE directory. II
this Iile exists when you start your JXTA
application. the JXTA ConIigurator will run and
prompt you Ior new conIiguration inIormation.
(You can also remove the 4PEXJSVQ'SRJMK
Iile and then start your application again; The
JXTA ConIigurator runs iI there is no
4PEXJSVQ'SRJMK Iile.)
However. as I was sitting behind a Iirewall. I also
needed to select appropriate relay settings to get
JXTA working. In order Ior the client and the
server programs to see each other I had to
conIigure both programs with 'Act as a Relay¨
and 'Use a Relay (Required iI behind
Iirewall/NAT)¨ options turned on. It is important
that both programs have both options turned on. I
played around with various combinations and
Iound that it worked only when both options were
turned on Ior both programs. Otherwise. the
programs got stuck in an endless waiting cycle
and never communicated with each other. Eor
your convenience. I have captured those screens
and attached them here.
As you have probably noticed. JXTA
ConIigurator provides you with many options.
This makes JXTA quite Ilexible. However. it
creates certain complexity Ior the novice. It may
take some time to experiment and to Iigure out
the correct setting. I wish there were a wizard
interIace that has two simple choices. 'direct
connection to Internet¨ and 'sitting behind
Iirewall/NAT¨. This approach would be
particularly convenient iI it would pick up proxy
settings once instead oI requiring them to be
entered twice. Iirst while loading the relay and
rendezvous host. and then a second time. during
setting oI the proxy hosts. Additionally. the port
number setting could be consolidated into one
box. i.e. 9704 across both 'manual¨ and
'incoming¨ boxes.
Figure 2 Receiver setting #1
March. 2004. P2P Journal
21
Figure 3 Receiver setting #2
Figure 4 Sender setting #1
Figure 5 Sender setting #2
3.2 The Deprecated API
AIter correctly setting the network options. I was
able to Iully compile and execute the
'PipeExample¨ example Irom the programmer`s
guide. However. I ran into problems when I tried
the 'BidirectionalPipeService¨ example. Eor this
example. I was able to compile the source code
without any problem. However. when I ran the
program on JXTA 2.2.0 release. I got a
'NullPointException¨ error on the binding as in
BidirectionalPipeService.bind(iava.lang.String
PipeName).
Apparently. BidirectionalPipeService API has
been deprecated since then.
3.3 Tutorial Program
At this point. a logical choice was to ask Ior help.
I wrote an e-mail to the discuss(fxta.org e-mail
list requesting assistance. I wrote that the
'BidirectionalPipeService¨ had been deprecated
and that I wanted to learn how to use the
'JxtaBiDiPipe¨ API. Within one day. I received
March. 2004. P2P Journal
22
e-mails pointing me to a page on JXTA.ORG`s
website Ior tutorials and examples. That URL is
http://www.ixta.org/proiect/www/Tutorials.html I
was able to download examples Irom that page
showing how 'JxtaBiDiPipe¨ API works.
3.4 Tracking down API changes
The most current 'JxtaBiDiPipe¨ example was
1.6. released on Eebruary 3. 2004. So. I tried to
compile those source Iiles. On the Iirst try. I got
the Iollowing errors.
JXTAServerPipeExample.iava
-cannot resolve symbol
method sendMessage (net.ixta.endpoint.Message)
JXTABidiPipeExample.iava
-cannot resolve symbol
method sendMessage (net.ixta.endpoint.Message)
-cannot resolve symbol
method setReliable(boolean)
I decided that I should check the Javadocs Ior
causes. However. I could not Iind those methods
in the JXTA 2.2.0 documentation.
This caused me to send another e-mail to the
JXTA discussion group asking Ior help.
3.5 3XTA 2.2.1 branch and libraries
Erom the answer e-mail. I learned that the 1.6
version oI 'JxtaBiDiPipe¨ example works with
JXTA 2.2.1 branch which will be release around
March 15. (Version 1.5 oI 'JxtaBiDiPipe¨ works
Ior 2.2.0 platIorm.)
So. I downloaded the JXTA 2.2.1 build. On the
Iirst try. I was able to compile but not run those
programs. I decided that Iurther investigation was
needed. Reading Irom error messages. I realized
that I was missing libraries. i.e. Log4J. Bouncy
Castle security. Cryptix. etc. I loaded those
libraries iars Irom JXTA.ORG`s website at
http://download.ixta.org/branchbuilds/index.html
and unzipped them. (ixtalib.zip)
By the way. the Junit test result Ior 2.2.1 branch
is at
http://download.ixta.org/branchbuilds/test/iunit-
report.html
AIter pointing the CLASSPATH variable to those
new libraries. I was Iinally able to compile and
execute the example.
3.6 Total time and effort
I began my JXTA reIresh course almost two
weeks ago. Between reading through e-mails and
documentations and working with code. I spent
close to 30 35 hours. This was a productive
exercise as it allowed me to gain a more detailed
understanding oI the JXTA 2.2.x architecture and
its programming model. Although I am not yet a
JXTA guru but I Ieel comIortable working with
existing code and making changes.
4 P2P GO
P2P Go is an online game written by David
Savage oI Morgan Spenser Consulting group. He
has done a wonderIul iob writing this game. I
believe that his program is the world Iirst P2P
game Ior Go.
As a little bit oI history. Go is an oriental game.
originating in China over 2.000 years ago. It is a
simple strategy game involving black and white
stones circling and counter-circling each other.
Over time. it has spread widely in East Asia.
Now. it is actively played around the world.
(Even in the movie 'A beautiIul mind¨) I am
actually an avid Go player. However. Go did not
evolve as much Irom the original Iorm in
comparison with Chess and Chinese Chess. Go`s
March. 2004. P2P Journal
23
chieI drawbacks are that it is time-consuming and
somewhat repetitive.
Using P2P Go is easy and straightIorward. AIter
several iterations to work out network issues and
various kinks. the latest version is 0.6 (See
http://go.ixta.org/Go_Downloads.html).
Because David lives in England and I live in
Dallas. playing P2P Go involved extending
traIIic across the Atlantic Ocean. At this moment.
the number oI JXTA users communicating across
the Atlantic Ocean is low. Because JXTA uses a
decentralized P2P model. peer connectivity and
system perIormance can be inIluenced by the
number oI users online. Additionally. I was
behind a Iirewall that occasionally 'ate¨ some IP
packets. As a result. we experienced the 'network
Iragmentation¨ problem. meaning we could not
see each other Ior a long time and the traIIic Ilow
was sporadic and unreliable.
To address those issue. P2P Go has three network
options.
o Connection timeout is how long it'll wait
when trying to bind to your player pipe
advertisement so a small value means
there'll be lots oI attempts but it'll timeout
rapidly. So. with long latencies this is
probably bad.
o Max Idle Time is the maximum time a player
can be quiet beIore the app will automatically
generate a ping to see iI the client is still there
- iI the ping is not responded to (handled by
app) then the client assumes the player has
gone.
o Packet Timeout is the length oI time it
should take Ior a packet to be acknowledged
(iI it takes longer than this then another copy
oI the packet will be sent). The app /should/
handle duplicates graceIully. Short values are
good Ior leaky connections as iI a packet goes
missing it will be resent automatically -
however it can be overly noisy iI the network
is behaving itselI (unlikely).
The above values are expressed in seconds. We
used a 120/120/5 combination.
5 Conclusions
Those exercises have helped me to learn a lot
about the nuts and bolts oI the JXTA platIorm as
well as gaining Iirsthand experience in the truly
P2P computing situations and how to conIigure
application settings to compensate Ior network
situations. Clearly. JXTA is an important
technology. I hope it will become a Ioundation
element Ior building the 'dialectic web¨.
I would like to spend more time on this
technology in the coming months. I am interested
in several areas.
1. Rapid Application Development (RAD)
Proiect JXTA currently has a subproiect
Ior a plugging module to the Eclipse
development tool. I hope to test drive that
in the Iuture.
2. Round-trip engineering This is probably
associated with the above topic. I also
want to see graphic artiIacts that I can use
with Rationale Rose. Visio. or Magic
Draw. In Iact. this reminds me oI my last
month discussion about P2PML.
3. Improved backward compatibility This
will be crucial in order Ior JXTA to
become enterprise ready. Being an open
source proiect. developers are willing to
play around with diIIerent options.
However. in corporate IT settings where
proiect managers closely look at costs.
time. maintainability. there will be much
consideration on the platIorm`s backward-
compatibility issues.
March. 2004. P2P Journal
24
4. More active user community When I
had played P2P Go with David. I
experienced the 'network Iragmentation¨
problem Iirsthand. The problem was not
caused by JXTA`s design. Rather. it was
due to low user activity and that I was
behind a Iirewall. In a peer network.
having more users means that there are
more traIIic routes between two end-
points. (JXTA users can set up their
computers as relay and rendezvous peers.)
In the layman`s term. more users translate
into that there will be better system
perIormance and connectivity. To attract
more users. a P2P platIorm needs to either
build more useIul applications or to Iind
creative ways to retain the existing user-
base. We need to move Proiect JXTA
Irom a research proiect to become a
mainstream programming platIorm.
5. Integration oI JXTA with middleware
technologies I have wanted to examine
this area Ior some time. However. as the
current economical state is still somewhat
depressed. there are tight spending
controls in place Ior investing in new
technologies. I hope to see this situation
improve as well as integrating /
embedding JXTA technology with rule
engines & various messaging systems.
e.g.
o Java Expert System Shell (Jess)
http://herzberg.ca.sandia.gov/iess/.
o Rule Markup Language (RuleML)
http://www.dIki.uni-kl.de/ruleml/
o JSR 94: Java Rule Engine API
http://www.icp.org/en/isr/detail?id÷09
4
o Business Rules Markup Language
(BRML)
http://www.oasis-
open.org/cover/brml.html
o Java Messaging Service
o Web services and JXTA bridge
http://i-x-w-s--gw.sourceIorge.net
o Java Connector Architecture (JCA).
particularly using JXTA as a possible
data source Ior JCA.
Thanks to:
o Mohamed AbdelAziz oI Sun Microsystems. Inc.
o Stephen Smith oI the University oI Whales
o And. other people who answered my e-mail
inquiries.
About the Author
Raymond Gao is the editor-in-chieI Ior P2P
Journal. He Iounded P2P Journal in early 2003.
He has a proven track record involving
enterprise-level and distributed computing
proiects. He has spoken widely and is well
published. He is interested in seeing P2P
computing being a transIormation technology Ior
the way people work. live. and entertain. His
other interests include music. oil painting. travel.
and writing. He can be reached at
raygao(comcast.net or (972) 530-4562.
Unity oI the world British soldier.
Erench grenadier. and Norwegian troll.
March. 2004. P2P Journal
25
3XTA 2.0 New Features & Benefit Summary
Bi-directional TCP/IP transport to improve resource consumption
HTTP supports http 1.0 and 1.1 protocols.
Separate relay Iunctionality Irom HTTP transport to gain modularity
Support Ior TCP/IP relay Ior improving NAT traversal perIormance.
Dynamic discovery and connection to relays Ior improving reliability and load-balancing
Dynamic discovery and connection to rendezvous Ior improving reliability and load balancing
Relay Iailover Ior improving network reliability
Rendezvous Iailover Ior improving network reliability
Asynchronous endpoint getMessenger Ior improving resource consumption
Normalized behaviour oI synchronous and asynchronous endpoint messengers
Support Ior addressing hints via route advertisements Ior improving route resolution
UniIying route management through route advertisements
Converted route discovery to use resolver service Ior uniIying all resolutions under the resolver
service
Introduce rendezvous peer view to manage rendezvous super-peer network to reduce resolver
query traIIic
Pluggable walker (limited-range walker) to route query within rendezvous network
Improved threading and resource allocation and reduce memory consumption
Replace Iile based and in-memory CM index by Btree Xindice database to reduce memory
consumption and improve CM perIormance
In-memory CM index now stored in Xindice database
Replace CM expiration scheduler thread by introducing database expiration records
Introduce Shared Resource Distributed Index (SRDI) to share index on rendezvous network
(Distributed Hash Table) Ior optimizing resolver query lookup.
Pre-cooked ID Iactory (Group ID)
User's Advertisement deIinable indexing
JxtaSocket stream based bi-directional pipe Ior ease oI development
SRDI based PipeService (Unicast. and Virtual Jxta Group multicast). Discovery. and
EndpointRouter
March. 2004. P2P Journal
26
Key Differences:
1X1A 2.ô 1X1A 1.ô
Bi-directional TCP/IP transport
Supports uni-directional TCP/IP transport
Support Ior HTTP 1.0 and 1.1 protocols
Supports HTTP 1.0 protocol
Separate relay Iunctionality Irom HTTP
transport
No separate relay Iunctionality Irom HTTP
transport
Support Ior TCP/IP and HTTP relays Support Ior HTTP relay
Dynamic discovery and connection to
relays and rendezvous
No Dynamic discovery and connection to
relays and rendezvous
Asynchronous endpoint connection Ior
improving resource consumption
No Asynchronous endpoint connection Ior
improving resource consumption
Pluggable walker (route query within
rendezvous network)
No Pluggable walker
Uses Btree X Indice database
Uses CM index
Uses Shared Resource Distributed Index
(SRDI) to share index on rendezvous
network
Doesn't use SRDI to share index on
rendezvous network
New Features:
o Improved threading and resource allocation to reduce memory consumption.
o Relay Iail-over Ior improving network reliability.
Source: JXTA proiect communications.
CaII For Paper
Dear friend:
The Peer-to-Peer Journal (P2PJ) is a bi-monthly journal that opens a forum to individuals and hi-tech firms
that are interested in applying, developing, educating, and advertising in the fields of Peer-to-Peer (P2P)
and parallel computing. P2P Journal intends to be the gathering place for people interested in reading and
writing articles or discussing and chatting about P2P, instant messaging (ÌM), collaborative computing, file
sharing & distribution tools & protocols, and parallel computing topics, such as grid and cluster computing.
The Editor-in-Chief is now inviting you or your friends to submit papers or letters for publication in P2PJ.
Articles, whitepapers, product reviews, discussions, and letters or short communications to the journal are
accepted.
For writer's guidelines, see

http://p2pjournal.com/main/new_p2p_writers_guideline-mod.pdf
For document template see
http://p2pjournal.com/main/resources/p2pj_template.doc
Once an article is accepted for publication, P2P Journal retains its copyrights. Authors are granted rights to
reproduce their articles provided that they include a prominent statement: ¨The piece originally appeared in
P2P Journal¨ and add a clearly visible link to http://p2pjournal.com
P2PJ is intended to become a medium helping connect people and entities and disperse useful information.
We believe that through building a gathering place where people can exchange ideas and information,
everyone will benefit from it. Ìn the spirit of sharing and freely exchanging ideas, P2PJ also has an online
chat room that allows instant communication between online visitors.
Best regards,
Raymond F. Gao
Editor-in-Chief, P2P Journal
1
2
Content for 3uly / August, 2004 Issue
Editor-in-ChieI: Raymond Gao (raygao(comcast.net. editor(p2piournal.com)
Editors: Daniel Brookshier (turbogeek(cluck.com)
Luca Caviglione (cvgl(mac.com)
Contributing Editors: Julita Vassileva ( iiv(cs.usask.ca ). Lingling Sun. Ran Cheng. Weidong Han
P2P Journal is currently accepting articles Ior upcoming issues.
Copyright © 2004: Unless with explicit written permission Irom P2P Journal. no part oI this iournal may be recycled or re-
produced in whole or parts.
Cover Image: "Venice. A city oI Enchantment". A painting by Raymond Gao. 2000. showing an evening in Venice.
(Additionally. we have a "call Ior the cover image" Ior upcoming issues oI P2PJ. Submit your artwork to raygao(comcast.net. Sub-
mission does not guarantee the automatic print oI your artwork.)
1
Project Venezia-Gondola (A Framework for P-Commerce)
By Raymond Gao
Proiect Venezia-Gondola is an application platIorm Ior Peer-to-Peer commerce (P-
Commerce).
14
Stimulating User Participation in a File-Sharing P2P System Support-
ing University Classes
By Julita Vassileva. Ran Cheng. Lingling Sun. Weidong Han
Comtella is a tool used by the Computer Science Dept. oI the University oI Sas-
katchewan to share documents and URL links.
24
Editor`s Note
25
3ob Posting
3
Abstract
A novel proiect named Venezia-Gondola (Proiect V-G) was
presented. which describes an application platIorm that enables
the activities oI Peer-to-Peer commerce (P-Commerce). A new
pattern called the Inverted Model-View-Controller (IMVC)
pattern was claimed that is suitable Ior P-Commerce. The
author also explains the principles oI the Proiect V-G and
possible architecture Ior Iuture development.
1 Introduction
E-Commerce as a business model allows people to
make transactions via the web conveniently.
Normally. a business model indicates the need to
make money. However. it is expensive to maintain
website inIrastructures - the conduit Ior maiority oI
E-Commerce activities. As a result. users will have to
pay Ior services. Additionally. the complexity oI the
centralized website administration requires good
content management services Ior serving both static
and dynamic contents. E-Commerce extensively
depends on web-browsers and HTML pages Ior the
user interIace.
Proiect Venezia-Gondola (Proiect V-G) proposes an
alternative architecture a decentralized commerce
model. Proiect V-G cleverly leverages the P2P
network as a conduit Ior commerce and greatly
minimizes inIrastructure costs. e.g. setting up and
maintaining server Iarms. paying Ior high bandwidth
pipes. installing applications. and administrating the
website. etc. Proiect V-G also provides extended
commerce capabilities. e.g. supports Ior 'traditional
online buying & selling¨ as well as 'bartering¨ and
'donation¨ oI goods and services. It is highly
customizable and can be used by any companies or
individuals. It uses the open-source model. Users and
developers can build simple plug-ins rather than
developing the entire application Irom scratch. In
Iact. we encourage developers to write enhancements
(pluggable modules) Ior the proiect. The unique
thinking presented in the proiect may even cause a
shiIt in the online commerce model Irom a 'cost per
transaction¨ model to a 'subscription Ior services¨
model.
1.1 1he Case for P-Commerce
1.1.1 1he A-1ier Architecture
The N-Tier architecture is widely accepted Ior
building E-Commerce websites. The N-Tier
architecture separates presentation. business logic.
process management. persistence (database). and
integration into separate layers. N-Tier architecture
oIten have many components. e.g. application
servers. web servers. portal servers. directory servers.
workIlow and integration engines. databases. etc.
(See Eigure 1) HTML/XML. CSS. Javascript. and
DHTML technologies are staple technologies Ior
providing Iront-end and graphic user interIace (GUI)
services. The business logic tier depends on
specialized middlewares. The catalog is stored in the
database. And. integration adaptors retrieve content
Irom backend Enterprise InIormation Systems (EIS).
Project Venezia-Gondola
(A Framework for P-Commerce)
Ravmond Gao
Editor-in-Chief. P2P Journal
mailto.ravgao(comcast.net
(972) 530-4562
5609 Harbor 1own Drive
Garland. 1X 75044
4
Eigure 1 The tools Ior E-Commerce
1.1.2 Weakness of Centralized Models
The current practice Ior building E-Commerce
website depends on centralization. That practice
emphasizes managing content and transaction logic
Irom a single point. That practice can potentially lead
to a 'single point oI Iailure¨ situation. Centralization
may also mean that user`s local settings are
overridden by central policies. Sometimes those
global policies are not appropriate to the local
situation and cause inconvenience. Integration is
another issue. It can become diIIicult to integrate two
or more complex websites that were initially
designed as stand-alone units. That situation is
worsened by business` need to produce positive
Return On Investment (ROI) on proiects.
Online commerce requires reliability. availability.
and scalability. When a customer has trouble with a
down website. he/she may never come back.
However. maintaining a high perIormance websites
Ior large number oI users can be an expensive and
challenging task. The inIrastructure alone can cost a
lot oI money Ior soItware. powerIul servers.
bandwidth. and a team oI specialists. system
administrators and support people. These large
centralized systems also need to worry about
computer viruses. proIessional/hobbyist hackers.
worms. denial oI service (DOS) attacks. and illegal
snooping oI theirs. Eventually. all those costs trickle
into every business transaction. Users will have to
pay Ior those centralized services.
Web-based applications are resource-intensive. Eor
every click. a new page needs to be generated and
sent to the user. Taking an online catalog application
Ior an example. the catalog is re-loaded by every user
and oIten multiple times. Even with caching oI web
pages. this is still a huge waste oI bandwidth that
must be supported in enterprise data-centers and
equipments. All those waste translates into cost Ior
the business who passes onto users. Now imagine a
Iellow trying to giveaway his used soIa or sell his
car. That person must either build his own site or use
someone`s hosting service. which is not Iree by any
means. And. that cost may cause some people to
Iorgo those activities.
1.2 Whv use P2P Instead of Client-Server?
Centralized website can be very complex. And.
complexity drives up the cost. Building a simple
Business-to-Business (B2B) website can range Irom
hundreds oI thousands oI dollars to millions. On the
other hand. Peer-to-Peer (P2P) is very simple. Each
peer behaves as both a client and server. Simplicity
means less maintenance and consequently is cheaper.
P2P also minimizes the eIIect oI DOS attack. Internet
connects millions oI homes and businesses. At each
access point there maybe one or more computing
devices. Each device has its own processor. storage.
memory. and network connectivity. And. each device
maybe running a slightly diIIerent operating system
and has diIIerent virus scanners. In the event oI a
DOS attack. only a Iew computers will be aIIect. The
rest can continue to Iunction normally. P2P network
is more resilient than the client-server architecture.
1.3 What is P-Commerce?
Peer-to-Peer Commerce (P-Commerce) is an
alternative model to centralized commerce. It is
based on the ad-hoc relationship between individual
participants. It uses the P2P network Ior
inIrastructure.
There is a saying. 'the network is the computer.¨
5
Proiect V-G utilizes the P2P network as a conduit Ior
commerce. In eIIect. 'the network becomes the
market.¨ (See Eigure 2)
A transaction by nature is transient. It records an
event-in-time between two or more participants.
Since a transaction is a temporary phenomenon.
wouldn`t it be more cost eIIective to Iocus on that
event than investing large sums oI money on a
centralized website? By giving people autonomy.
participants will be in control instead oI an arbitrary
central authority. The business process becomes
more eIIicient as well. Under the P-Commerce
model. buyers and sellers rather than iust the seller
control a transaction. P-Commerce (P-C) becomes an
equalizer Ior both parties.
Figure 2 P-Commerce Model
P-Commerce has many other advantages.
o Users have choices on selecting which
rich client Ior graphic user interIace
(GUI). which enables more IulIilling
experience than with thin clients and
browsers.
o Buyers and sellers can have real-time
conversation beIore. during. and aIter the
transaction.
o Multiple parties can engage in
conversations and share inIormation in
both public and private venues.
o It is easier to implement agent-based
computing. especially mobile agents.
Mobile agents require tight security when
done in a server. With P-C. the agent
interaction is between the agent and the
target.
1.3.1 XML and P-Commerce
XML is a key component to P-Commerce. Because
oI the selI-documenting nature and standard schemas
available. XML enhances and eases compatibility
between applications written by diIIerent vendors or
Ior diIIerent purposes like the diIIerence between a
seller. a searcher. and a buyer. Imagine a seller that
creates a schema Ior selling cars. The schema can
contain inIormation about options. perIormance. and
the condition oI the car. A buyer may not have a
plug-in to examine the data Irom the seller. however
they can look at the data with a standard viewer that
converts the XML to a humanly readable Iorm. The
user can also use the tagged content in the XML to
build search agents that can locate other sellers using
the same or similar schemas. (Association)
1.3.2 Benefits
P-Commerce empowers people. P-Commerce is
more Ilexible Ior the seller. prospective buyers
(searchers). and the buyer. Sellers can create rules
similar to a centralized web-based system. but there
is more Ilexibility to how you sell by using plug-ins
that apply speciIically to your product and style oI
sale. Searchers and buyers also have increased
Ilexibility by creating agents Ior both searching and
buying products or even bidding on products.
P-Commerce is very Ilexible and has several
technical advantages. It allows direct interaction
between participants. It more accurately models a
transaction where peers at the network edge interact;
the 'transaction logic¨ and 'content¨ are distributed.
The P2P network can also scale better than the
centralized architecture. P2P can circumvent 'the
single point oI Iailure¨ problem in some cases.
Individual peers can make decision on whether to use
6
a thin or a Iull-Ieature application.
P-Commerce helps to cut down Iees charged by the
middleman in a business transaction. It allows direct
interaction between sellers. buyers. and shoppers (a
person who is looking and has not yet made his/her
mind.) Because the true source oI a product or
service is exposed. there will be more opportunities
and competition. Competition helps to drive down
costs and to stimulate new innovations.
P-Commerce can also build a network oI reIerrals
(Iriends and partners) to help cross-sell goods and
services. The recent success oI 'Eriendster¨ and
'Plaxo¨ Iurther validates the value oI social network.
Using the market Ior pedigree dog as an example.
smart buyers are interested in the quality oI the dog.
which includes the dog`s lineage and awards the
dog`s parents have garnered at dog shows and
competitions. A good buyer would reserve a puppy
Irom a planned litter than going to puppy mills.
Breeders also need to locate other dogs to add to their
stock or to use as studs. In those situations. reIerral
is a more powerIul and reliable venue than direct
marketing. In many cases. the logic behind those
activities will be too complex Ior traditional E-tailers
and must be addressed on an individual basis.
P-Commerce encourages creativity. It allows non-
monetary based transactions. i.e. bartering (exchange
& trade). goodwill (giving away merchandises and
services based on certain criterions). It allows
business to come up with imaginative new services
and not Ieeling pressured by price wars. Quality and
originality become more important bottom lines.
1.3.3 Project J-G - A Aew Direction In
Commerce
Proiect V-G is the Iirst P2P application Iramework
aimed at a general-purpose commerce system. It adds
'bartering¨ and 'goodwill¨ Iunctions (Eigure 3) and
additional creative business processes. It has three
components: a P-Commerce network called "Venezia
Network". a P-Commerce engine called 'Venezia¨.
and a graphic user interIace call 'Gondola". Proiect
V-G is experimenting with a new computing model
called the Inverted Model-View-Controller (MVC)
pattern. (See section 2)
Proiect V-G is also an open-source proiect to
promote its expansion into various markets and
business models. Developers can write their own
plug-ins that extend the system to add new product
categories. methods oI making a sale or bidding. and
extend the way that a user searches Ior and buys
products.
Figure 3 Comparing Two Online Commerce Models
2 P-Commerce, Model and Patterns
AIter analyzing several P2P networks and surveying
general peers behaviors. we have decided to use the
Inverted Model-View-Controller (IMVC) pattern Ior
Proiect V-G.
7
2.1 1he MJC Pattern
The Model-View-Controller (MVC) pattern has its
roots extending back to IBM mainIrame computing
environments. The MVC pattern separates a
complex application into three tiers. Those tiers are
Model. View. and Controller. The Model represents
the underlying data-store as well as access. update.
manage. and delete Iunctions. The View component
displays those data in a useIul Iormat Ior the user.
And. the Controller translates user actions and
dispatches appropriate methods on the Model. The
MVC pattern shields end-users Irom making system-
level changes to the data-source. i.e. dropping tables.
changing schema. shutting down database. etc.
Figure 4 The MVC Pattern
2.2 Patterns observed from P2P Applications
The P2P network is based on ad-hoc relationships.
Content is dispersed throughout the entire network
and not aggregated on a single web-server. We
reviewed articles about leading P2P applications. e.g.
Gnutella. Napster. Limewire. and Iound some
general patterns.
2.2.1 Reciprocal Relationship
Peers are independent entities. Each peer is a selI-
contained unit that is both a client and a server. Peers
make individual decisions oI whether to consume
content. to add new content. to route inIormation. or
to observe activities in the system. The interest in the
system is similar to a publish and subscribe model
where some peers are the creator oI data. services. or
transactions while others are the consumers oI data.
services. and the subiect oI a transaction.
2.2.2 Browsing vs. Providing Information
The most popular activities on a P2P network are
'searching¨. 'browsing¨. and 'downloading¨
content. Some studies have shown that only 10° oI
altruistic individuals actively add new material.
There are some similarities in the online commerce
situation. Most people are shoppers. It takes time.
money. and eIIort to set up shops online. II a person
only has one or two items Ior sale. giving them away
(donation) maybe easier than trying to setup a shop.
Merchants are people who Irequently sell things
online and manage to recoup initial costs and to
make a proIit. Entrance barriers cause there will be
more buyers online than merchants. II we use the
market-driven model. excess demand over supply
will provide incentives Ior people to get involved.
else the market has diminished value Ior producers.
2.3 1he Invert MJC Pattern
In the P2P network. peers can Ireely add new
content. provide comments. and summarize Iindings.
II one imagines that the P2P network is a large data
source. then one can think that peers provide contents
Ior 'tables¨. peer-groups memberships are analogous
to 'database schemas¨ Ior grouping several peers
together.
The Inverted MVC pattern is a derivative oI the
MVC pattern. A key diIIerence between the MVC
pattern and the IMVC pattern is the 'access control¨.
The MVC patterns shields end-users Irom making
direct changes on the data-source. e.g. shoppers
cannot randomly add new products to a web-store`s
catalog or delete product listings. In the P2P network.
the data-source is exposed to the public. Anyone can
add new content and even annotate meta-
inIormation. like indexes. to aIIect routing and items`
hit ratios. Because any peer can act as a server.
occasionally. peers can provide conIlicting data. i.e.
Peer A advertises the availability oI version 1.0 oI a
soItware. Peer B advertises the availability oI version
1.0.1. and Peer C advertises version 1.0.1 with Beta
service pack. Thus. a good P2P application
architecture should plan Ior the inconsistency in the
data model.
8
On a traditional website the web-site administrators
are responsible Ior setting up its indexing engines
and permissible Iilters. In a P2P network. there is no
centralized system administration. Each user sets up
his/her own Iilters and has a 'window¨ into the
'network data-source¨ via his/her local application.
(See Eigure 5) A peer sees and works with one
'view¨ at any single point oI time. Because the
overall data-model can become inconsistent. two
peers may get diIIerent results with an identical
query.
Figure 5 The Inverted MVC Pattern
Several P2P platIorms have introduced the 'super-
peers¨ concepts. e.g. Rendezvous Peer Ior JXTA.
reIlector Ior Gnutella. and in EastTrack. Super-peers
are 'aristocrats¨ oI a P2P network and provide basic
peers with services. e.g. routing. proxy through
Iirewalls. and caching service oI Irequently used
items. The more clients a super-peer has. the more
inIluence that super-peer has in a P2P network.
Clients oI that super-peers oIten develop similar
'perception¨ even though that 'perception¨ may or
may not match the overall network data model which
itselI maybe inconsistent at times. The super-peer
exerts 'controls¨ by having many dependent clients.
This shows a diIIerence. in a P2P network the
'controllers¨ are distributed; and in the client-server
model that is centralized and is bundled with the
'data model¨. The membership in peer-groups
provides additionally Iorm oI Iilter and control.
2.4 Suitabilitv of the IMJC pattern
The Inverted MVC pattern helps us to understand
how P2P applications work and provides us a mental
model that separates the data. the presentation. and
the process Ilow. A model usually has two aspects.
structure and behavior. The IMVC structure is loose
on the data-model whereas the MVC model is tight
on the data-model consistency. In the MVC pattern
when the database is corrupted. the entire application
is hosed. A P2P network is designed to handle cycles
oI disorder and restoration. Every time a new peer
ioins and leaves the network. the 'data model¨
changes. In a large network with thousands oI peers.
cycles can Iluctuate rapidly. The use oI super-peers
may help to smooth out Iluctuations and bring
stability to a P2P network and improve eIIiciency.
P-Commerce allows peers making transactions
directly. When that happens. the transaction logic
MVC IMVC
Model BuIIered Irom
direct modiIica-
tions
Externalized. any-
one can aIIect the
'model¨. i.e. add
content and anno-
tate meta-models
Logic &
Control
Centrally man-
aged
Decentralized and
competing
View Managed by the
'controller¨.
diIIerent
'views¨ match
the same 'data-
DiIIerent 'views¨
may reIlect totally
diIIerent 'data-
sets¨.
Application The consistency
oI the 'model¨
is absolutely
essential. The
'controller¨ re-
inIorces the
data-model con-
sistency.
Inconsistency oI
the data-model
should be
planned. The
'view¨ drives
end-user behav-
iors.
9
becomes decentralized. Under the MVC pattern. the
transaction logic resides on a central website and is
associated with the 'model¨ and mediated by the
'controller¨. In a P2P transaction. that is no longer
true. Eor example. two buyers are trying to purchase
a same red Eerrari Irom a dealer. When the Iirst
buyer agrees to the transaction. the second buyer may
not become aware oI the situation until he/she
receives a notiIication Irom the seller. However. the
seller has no obligation to let the second buyer know
until the second buyer asks. In a slightly diIIerent
situation. the Iirst buyer decides to abandon the
transaction. does that leave the seller hanging and
miss the opportunity to sell to the second buyer? In a
third situation. when the Iirst buyer withdraws Irom a
bid. should the second buyer be allowed to lower his/
her bid?
A possible solution to the above problem is to let the
seller bear the communication responsibility with
buyers. The seller can behave like a message queue
and create two bi-directional pipes to two buyers.
But. who is going to check the integrity oI the seller?
Alternatives one can use a super-peer to validate
activities. However. it causes centralization oI the
network.
3 Project Venezia-Gondola`s Goals and the
Design
3.1 Solution Statements
Proiect V-G is a P-Commerce application
Iramework. It allows participants to conduct various
decentralized business activities. e.g. buy. sell.
haggle. barter. bid. and goodwill. Proiect V-G
believes in that selI-governing marketplaces are very
eIIicient. DiIIerent products and services have
diIIerent characteristic. Likewise. trading and/or
bartering should have diIIerent guidelines. Having a
single marketplace Ior trading everything may cause
excess regulations and impede normal business
activities.
Proiect V-G provides tools (network services and
toolkits) and encourage establishing multiple P-
Commerce marketplaces. Those marketplaces can
have competing. cooperative. inter-dependent. and
consolidated relationships. as well as be selI-
standing. It provides an alternative to the mono-
marketplace approach because it is too complex to
Ior a single website to write and monitor all business
rules.
3.2 Architecture Overview
Proiect V-G three modules. The Gondola module
Iunctions as the Graphic User InterIace (GUI). a
Iacade to the underlying engine. The Venezia module
is the core that enables P-Commerce. And. there is a
third module Ior importing and parsing business
rules.
Figure 6 Project Venezia-Gondola Technical Architecture Model
The architecture Iollows the Inverted MVC pattern.
whereby the 'Model¨ is the Venezia P-Commerce
Network. Many users will spend maiority oI their
time browsing rather than adding new listings. The
'View¨ is the Gondola module. which acts as the
'windows¨ into the network. And. business rules are
used to control the Ilow oI inIormation and guide the
user`s interaction with the system. Business rules can
be iointly edited and are stored in the XML Iormat.
Applications create 'monitors¨ Irom importing
business rules.
3.3 1vpical P-Commerce Processes
Certain processes are recurring across most online
commerce activities. Those processes can be grouped
into Iollowing categories - Registration. Searching &
Browsing. Listing. Transaction. and Eeedback.
10
Figure 7 Project Venezia-Gondola's Common Capabilities
Additionally. there are utility Iunctions to support
above processes. e.g. Peer communication. Logging
oI transactions. Post-transaction critic and other
miscellaneous activities.
3.3.1 1he Registration Process
BeIore a User A can participate in the Venezia
Commerce Network. he/she must establish his/her
identity. To register. User A needs to have Name
(Eirst-name plus Last-name). E-mail address. Instant
Message ID. Phone number. Postal Address. and Zip
Code. Currently. we are using e-mail address to
identiIy each peer and that is set the Iirst time the
user runs the application. In the Iuture. we intend to
use pluggable module approach. allowing third party
security-service provider add-ons.
3.3.2 1he Searching Process
There are two directories. One is a list oI
merchandises. The other is a list oI users. There is
also a "map". linking merchandise listings to owners.
(See Data Model) Currently. we have implemented
an area code based searching mechanism. We plan
on adding geologic based searching Ieatures. i.e.
longitude and latitude.
3.3.3 1he Listing Process
Adding a new listing involves generating a GUID Ior
an item. conIirming that ID. and propagating that
listing in the network. The GUID creation is based on
owner`s UUID. item name. and a custom hash
Iunction. Each item will have Iollowing inIormation.
Product Specific
1. Name
2. Category
3. Location (using area code. map segment.
or zip code)
4. Keywords
5. Detailed description
6. Images & Sounds
7. Available Quantity
8. Price
9. Payment Options (Cash/Credit. Barter.
Goodwill)
Support Information
1. Documentation. user guide. etc.
2. Shipping inIormation
3. Contact inIormation. e.g. phone number.
e-mail. IM. etc.
4. ReIerence
3.3.4 1he 1ransaction Process
We are providing 'straight purchase¨. 'haggle¨.
'auction¨. 'barter¨. and 'goodwill¨ Iunctions in
Proiect V-G. Only with P-Commerce. 'giving away¨
and 'exchanging¨ goods and services becomes
valuable transactions model. Each transaction may
have additional subtypes and be inter-dependent. Eor
11
example. the auction process has the Dutch auction
as a sub-category.
4 The Data Model
Proiect V-G currently uses HSQL Ior the local data-
store. There are two primary tables. The 'User¨ table
stores the user speciIic inIormation. such as 'User
ID¨. 'Name¨. 'E-mail¨. 'Interests¨. etc. The 'Item¨
table keeps track inIormation about the merchandise.
The 'Item¨ table is linked to the 'User¨ table via
owner as a Ioreign key.
Secondary tables include 'Review¨. 'Transaction¨.
and 'SearchResult¨ tables. The 'Review¨ table is
used to keep track a user`s reputation. And. the
'SearchResult¨ table stores searching inIormation.
Einally. the 'Transaction¨ table is a temporary means
to store the transaction inIormation.
Figure 8 Project V-G Data Model
5 Observations
Proiect V-G is an ongoing proiect. During the
implementation process. several observations were
made.
1. Business processes Ior online commerce can
become very complex. Section 3.4 has shown
several typical P-Commerce processes. In
reality. those processes barely meet the 'tip oI
the iceberg¨. There are many other types oI
processes and variations.
2. It is important to keep the client binary
distribution to as small as possible. We are
currently building this proiect on Sun`s JXTA
platIorm. We have Iound that JXTA carries
many dependent libraries (JAR and ZIP Iiles).
The size oI the JXTA platIorm alone exceeds
6 megabytes. While broadband has become
quite common nowadays. Ior international
and dial-up users size remains an issue. We
hope to strip down the JXTA platIorm and
eliminate unused library Iiles.
3. 'Rendezvous pollution¨ poses a perIormance
problem. Currently. the JXTA`s conIiguration
utility allows any user to become a
rendezvous host. Because a peer can
disconnect anytime. it may leave its clients
waiting Ior an extended time. Additionally.
response Irom JXTA`s public Rendezvous
hosts maybe slow at times. (It could take up
to several minutes to resolve a connection.)
To work around those issues. we have set up
a private Rendezvous host that restricts access
to a predeIine peergroup. That private box
runs BEA`s JRockit as its Java Virtual
Machine on a Red Hat Linux 9.x platIorm. (In
the upcoming release oI JXTA. this problem
will be Iixed. But currently we can control
this in our own network via our custom
conIiguration.)
4. The conventional P2P searching method.
broadcasting queries. is ineIIicient Ior a large
network. It could potentially cause an
avalanche oI network activities. We are
working on a reIerral model. HopeIully. that
searching process will be more intelligent.
5. Security and trust are very important topics
Ior P-Commerce and can become very
complex. We hope that by using Pluggable
Authentication Model (PAM) architecture we
12
Raymond Gao is the editor-in-chieI Ior P2P Journal.
He Iounded P2P Journal in early 2003. He has a
proven track record involving enterprise-level and dis-
tributed computing proiects. He has spoken widely
and is well published. He is currently a chieI architect
Ior Nokia`s Business InIrastructure group. His other
interests include music. oil painting. travel. and writ-
ing. He can be reached at raygao(comcast.net or
(972) 530-4562.
can use third parties security modules with
service provider interIaces (SPIs).
6 Summary
Proiect V-G is an ongoing experiment to demonstrate
the validity oI P-Commerce. It uses the IMVC
model. Currently. we have two part-time developers
working on this proiect. Given the complexity oI P-
commerce. we certainly Ieel that our proiect will
beneIit Irom community involvement. Perhaps. we
can align our proiect with other open-source eIIorts.
We have a long wishing list Ior new Iunctions. We
hope that by opening up the source code. it will
encourage people to get involved.
o Enhanced Ior the GUI. i.e. rich-client.
skins
o PerIormance metrics tools
o Third party security modules and
transaction validation services
o InterIace with and save results to
accounting soItware like Quicken
o Agents. i.e. automatically Iind and update
new merchandise listings
o Management oI buyers. sellers. and
Iriends
o Pluggable product description modules
vs. writing the description Ior each
product Irom the scratch. Ior anything
Irom cars to car parts to the pedigree oI a
pure bred dog.
o Pluggable payment system allowing
COD. credit card. third party exchange.
barter. or even non-monetary like airline
miles or even community points.
Special Thanks to Daniel Brookshier and Johnson
Gao Ior reviewing this article and giving me many
useIul inputs.
References
1. Proiect Venezia-Gondola`s website (http://
venezia-gondola.net)
2. 'Proiect JXTA 2.0: Java
TM
Programmer`s
Guide¨. Sun Microsystems. Inc. May. 2003
3. Daniel Brookshier. Darren Govoni.
Navaneeth Krishnan. 'JXTA: Java
TM
P2P
Programming¨. SAMS Publishing. March
2002
4. Denis Urusov. 'JOSE A Java Open Source
Exchange¨. P2P Journal. January. 2004
5. Luca Caviglione. 'The 'dark¨ side and the
'Iorce¨ oI peer-to-peer computing saga¨. P2P
Journal. January. 2004
6. Ben Strulo. 'Middleware to Motivate Co-
operation in Peer-to-Peer Systems¨. P2P
Journal. March. 2004
7. Dimitrios Tsoumakos. Nick Roussopoulos.
'Probabilistic Knowledge Discovery and
Management Ior P2P Networks¨. P2P
Journal. November. 2003
8. Joseph J. Bambara. Paul R. Allen. 'J2EE
Unleashed¨. SAMS publishing. 2002
9. White. K. Peterson. B. Lheureux. 'New P2P
Raymond Gao is the Iounder
and the editor-in-chieI oI
P2P Journal. He is currently
a chieI architect Ior Nokia`s
Business InIrastructure
group. His other interests
include music. oil painting.
travel. and writing. He can
be reached at ray-
gao(comcast.net or (972)
530-4562.
13
Solutions Will RedeIine the B2B Supply
Chain¨. Gartner Research Note. 1 Eebruary
2003
10. R. Batchelder. 'Peer Spaces: The Web
Services Desktop¨. Gartner Research Note.
16 September 2002
11. Carl Lehmann. 'P2P In B2B¨. Meta Group
Research Report. 19. June. 2001
12. Raymond Gao. 'To P2P or P2P Too: A
discussion oI Peer-to-Peer and Related
Technologies¨. P2P Journal. July. 2003
(http://p2piournal.com)
13. James W. Cooper 'Java
TM
Design Patterns¨.
Addison-Wesley. 2001
14. Bo LeuI. 'Peer to Peer: Collaboration and
Sharing over the Internet¨. Addison-Wesley.
June 2002
15. Mark Buchanan. 'Nexus¨. W. W. Norton &
Company. 2002
16. Sun Educational Services 'Architecting and
Designing J2EE
TM
Applications¨. SL-425
14
Stimulating User Participation in a File-Sharing P2P System Sup-
porting University Classes
3ulita Vassileva, Ran Cheng, Lingling Sun, Weidong Han
Universitv of Saskatchewan. Computer Science Department. Saskatoon S7N 5A9 Canada
fiv(cs.usask.ca
Abstract
We have implemented a small-scale peer-to-peer based environ-
ment called Comtella. which allows Iaculty. graduate and under-
graduate students to contribute and share URLs oI class-related
resources. like academic and popular articles. The system has
been deployed Ior three months in a university course on ethics
and inIormation technology with thirty-Iive undergraduate stu-
dents. We deployed two motivational strategies to encourage
users to contribute resources. The evaluation results showed a
signiIicant increase in participation and the number oI contribu-
tions. Euture work will Iocus on ensuring mechanisms Ior collec-
tive quality control oI the contributions.
1. Introduction
Typically. most peer to peer (P2P) Iile sharing appli-
cations are large-scale. involving thousands oI peers.
They have been used Ior sharing music. video-clips.
movies and games and due to copyright issues have
been typically in the grey zone between legal and ille-
gal. There have been Iew attempts to build smaller
scale P2P applications to serve a particular organiza-
tion. There are speciIic problems Iaced in the develop-
ment oI small-scale P2P applications. and ensuring
presence. participation and contribution is the most
crucial one. A small-scale system can not rely on the
redundancy oI resources ensured in a large-scale sys-
tem. Ensuring that there are enough peers on-line is
crucial. since otherwise the Iiles shared by oII-line
peers are not available and the inIrastructure Ior
propagating queries suIIers. In addition to presence. it
is important to ensure constant Ilux oI new shared re-
sources. Otherwise the system quickly reaches a state
where everyone has downloaded all resources avail-
able which one is interested in. and there is no reason
to search in the system. since there is nothing new. In
a large system. like most successIul existing P2P Iile
sharing systems (KaZaA. eDonkey. BitTorrent etc.).
the huge numbers oI users participating and sharing
resources ensures that there are enough resources
available Ior search at any moment oI time. and
enough new resources are added. However. Ior small
scale systems. it is not trivial to ensure these things.
This paper presents our experience in developing a
successIul small-scale P2P system. We have devel-
oped a system called Comtella that allows sharing pa-
pers downloaded Irom the web. or web links to papers
Ior the purpose oI a research group or a class oI stu-
dents. It uses a Iorm oI physical centralization to en-
sure presence and motivational strategies to persuade
users to bring in new resources. The paper is organ-
ized as Iollows: the next section presents the Comtella
proiect. Section three discusses the Iirst experiences
and problems encountered. Section 4 reviews ap-
proaches Ior ensuring incentives Ior contributions in
P2P systems and online communities. Section 5
presents an implementation oI Comtella to support a
university undergraduate class. Section 6 presents the
strategies adopted in Comtella Ior motivating user par-
ticipation and section 7 the evaluation results. Sec-
tion 8 presents the main conclusions and directions Ior
Iuture work.
2. The Comtella Project
The Comtella system was developed at the Multi-
Agent. Decentralized. Mobile and Ubiquitous Com-
puting (MADMUC) lab at the Computer Science De-
partment to support graduate students in the laboratory
to share research papers Iound on-line |14|. Comtella
uses an extension oI the Gnutella 0.6 protocol |8| and
is based on a JTella client |11|. Each user needs to
download an application (called 'servent¨) that allows
sharing new papers with the community (typically.
15
PDE Iiles) and searching Ior papers shared by oneselI
and by the other users. The shared papers need to be
annotated with respect to their content as belonging to
a subiect category.
We did not want to include a heavy-weight Iull-text
search techniques on board oI the client and decided to
use a shared hierarchical organization oI categories
among the peers. because it allows both indexing new
documents and search in Iorm oI browsing through a
hierarchy which is a Iamiliar technique Ior users. simi-
lar to the way they store and locate Iiles on their hard
disks. In retrospect was not a wise decision. Iirst. be-
cause it is hard to make users agree on a uniIied taxon-
omy oI subiect categories and second. because it im-
plies a Iorm oI 'semantic¨ centralization Ior the P2P
system. We used a list oI categories that we believed
was well-accepted an extended subset oI the ACM
subiect category index. containing the areas oI interest
oI the department. However this category index turned
out to be outdated. large and complex. so we had to
develop techniques around this to allow users to delete
and suggest new categories and a community based-
process Ior modiIying the hierarchy categories. The
problem oI pushing this list back to the clients was
solved with periodic release oI new versions. but there
were compatibility problems since not all users up-
graded their clients regularly. We are currently look-
ing Ior better ways oI achieving a decentralized se-
mantic organization that allows a convenient way oI
indexing new papers and convenient search options.
Currently a hierarchical category list is used to clas-
siIy the shared papers. The user searches by speciIying
a category and receives a list oI all own papers and
papers shared by others related to this category. Erom
the list oI results. the user can download the desired
papers and view them in a browser. Thus the basic
Iunctionality oI Comtella is similar to several recent
systems which have attempted to harvest the eIIorts oI
independent libraries. web-catalogues and individual
users Ior sharing bibliographic inIormation and pa-
pers. most prominently LOCKSS (http://
lockss.stanIord.edu/). Bibster (http://
bibster.semanticweb.org/) and DAD |7|.
3. First Experiences and Problems
Comtella was used Ior three months in our department
on an experimental basis using our campus network
(10Mb/sec) which includes various platIorms: Win-
dows. Linux. Unix. Solaris. NetBSD and MacOS.
There were logistics issues. related to the Iact that the
system was Iully distributed. The necessity to have
one servent on each computer and the impossibility to
relate more than one servent to the same user meant
that the users who wanted to use the system at home
and in the oIIice had to always leave their servents
running on both machines. so that they could access
Irom work their own papers shared at home and in re-
verse. The user`s servents on the home computer and
on the work computer are iust like servents oI two diI-
Ierent users. with diIIerent ids. lists oI shared papers
etc. In order to access the papers shared by another
user. that user has to have his/her servent running and
in this case. to be able to access one`s own Iiles on the
other computer. one had to keep that computer (with a
Comtella servent on it) running. This proved to be a
problem. because users typically switch oII their home
computers when they are at work. The users tended to
start their servents only when they wanted to search
Ior papers and to quit them aIterwards. Due to the
relatively small size oI the user group (25 users). this
lead to very Iew servents being on-line simultane-
ously. so typically there were very Iew (iI any) results
to a query.
The problem oI participation is well known also Ior
large scale systems. It is very important to ensure a
critical mass oI on-line servents to maintain an inIra-
structure that guarantees successIul searches and at-
tracts more users. Bit Torrent Ior example. uses a pro-
tocol that Iinds and uses several diIIerent sources to
download a single Iile to ensure redundancy (iI some
oI them shut down) and better speed oI downloads.
But to achieve this redundancy Bit Torrent too needs a
critical mass oI users who keep their servents running.
Einally. we observed that even when most oI the users
keep their servents running Ior a certain time. this is
not enough to ensure a useIul system. II there are no
new resources iniected regularly into the system (by
16
users bringing in and sharing new papers). very soon it
makes no sense Ior a user to search in his/her main
area oI interest since there is nothing new in the sys-
tem that the user has not seen or downloaded beIore.
Ultimately. the system reaches equilibrium where eve-
ryone has all papers that everyone else has. The shar-
ing system is then useless. In order to achieve a dy-
namic and useIul system. the users have to share new
papers regularly. Motivating users to contribute new
resources is an important problem that can not be
solved on a protocol level. The user needs to be in-
volved and motivated to Ieel as a part oI a community
and incentives need to be built in to stimulate active
participation.
4. Incentives for User Participation
Studies on P2P networks |1| show that only Iew oI the
peers contribute resources. Many existing p2p sys-
tems have developed their own strategies to motivate
users to make contributions to their virtual communi-
ties. Only several more characteristic examples are
listed below.
Simple solutions to this problem have been used in the
popular Iile-sharing systems like KaZaA and
LimeWire. Typically. the interIace makes terminating
the servent particularly hard Ior the user: even when
the user clicks the 'close window¨ box. the applica-
tion is not shut down. but runs in the background.
passing messages and serving requests.
"Direct Connect" (www.neo-modus.com) and
Limewire deploy a simple strategy to ensure user con-
tributions they Iorce users to share a minimum
amount oI resources. II a user Iails to meet the re-
quired quota. his or her access will be limited or com-
pletely denied. Although this method encourages dedi-
cated users to contribute. there is no data about the
numbers oI users who decided not to participate at all
because oI this constraint. Anecdotal data suggests
that many people tend to not ioin such exclusive com-
munities since they are Iorced to contribute beIore re-
ceiving any beneIits.
Many authors have proposed theoretical models Ior
economic incentives in terms oI micro-payments Ior
uploads and downloads |4.9|. Moio Nation
(www.moionation.net) attempted to introduce an elec-
tronic currency and micro-payments to provide eco-
nomic incentives Ior sharing resources. The users
needed to pay Ior each download and the users who
share resources got paid. However. the approach was
not successIul and Shirky |12| pointed the reason Ior
the Iailure in the cognitive cost Ior each transaction.
The act oI buying anything. even iI the price is very
small. creates mental transaction costs. that is. the en-
ergy required to decide whether something is worth
buying or not. People would rather pay a Ilat rate than
think about the cost oI every small purchase.
Another way to promote users to participate and con-
tribute is by rewarding the active users with better
quality oI services (Iaster downloads). as Kazaa Lite
and eMule do. The systems record the actions oI users
and maintain numeric participation levels Ior each
user. The speed oI downloads the user can get is deter-
mined by the user`s participation value. which seems
to be calculated as a Iunction oI the diIIerence be-
tween how much resources (in MB) have been
downloaded Irom the by other users and how much
resources the user has downloaded Irom others.
The main problem with this strategy. as well as with
other economic-based strategies is that they do not
reward users who share Iiles that are not oI wide com-
mon interest. Such users Ieel Irustrated and treated
unIairly. they withdraw and the variety oI Iiles oIIered
decreases.
Similarly to P2P systems. some server-oriented online
communities use various mechanisms to motivate peo-
ple to ioin and contribute high quality resources
(typically. posts). Although these online systems are
diIIerent Irom P2P systems in terms oI architecture.
the ideas oI their motivation strategies can be applied
to P2P systems. The best example in this category is
Slashdot (slashdot.org) which measures the users`
contributions to the community in a unit called
17
'karma¨ |10|. II the user`s posts are highly rated by
the moderators. the user earns karma in the system
related to some special privileges. Eor example. the
user`s subsequent posts begin liIe at a higher rating
than usual. The users with high karma are more likely
to be chosen as moderators in the Iuture. Users who
are moderators can rate other users` posts. consuming
their own karma. That means the users with high
karma have more ratings to give away and are there-
Iore more inIluential in the community. This strategy
also stimulates the members to submit high quality
posts.
We chose to study approaches that are not based on
payment and instead looked into the area oI social
psychology on research about how people can be mo-
tivated to do particular things. We Iound two persua-
sion strategies - deployed in advertisement and cus-
tomer relationship management (CRM) which we be-
lieve can be useIul Ior our purpose. These include
visualization oI the community |3| and introducing a
concept oI hierarchical community memberships.
based on the user`s contribution to the community.
We applied these two strategies in a new motivational
version oI Comtella which was deployed in an under-
graduate class on Ethics and InIormation Technology.
In order to enable Comtella to serve as a tool to sup-
port a class some modiIications Irom the original de-
sign were required. which are presented in the next
section. A detailed description oI the motivational
strategies and the experiment results are presented in
sections 4 and 5.
5. Comtella in the Ethics Class
'Ethics and InIormation Technology¨ is a Iourth year
undergraduate computer science class at the Univer-
sity oI Saskatchewan discussing topics related to pri-
vacy. Ireedom oI speech. intellectual property. deskill-
ing. workplace issues. outsourcing. as well as proIes-
sionalism and ethical decision making. The class uses
an excellent textbook |2|. However. it presents mainly
US-related context (legislation and example cases).
The nature oI the material demands that there is a lot
oI discussion. since there are many 'hot¨ issues (Ior
example. iob outsourcing. soItware patenting) and le-
gal case-developments (legislation related to intellec-
tual property and Iile sharing Ior example).
Comtella was introduced in this class as a tool Ior stu-
dents to Iind and post on-line articles and materials
related to the weekly themes oI the class. In previous
class oIIerings the students had to Iind and post class-
related web-links on their personal websites dedicated
to the class. More details and comparison oI the two
approaches oI sharing class materials can be Iound in
|15|.
Three modiIications oI the Comtella system were nec-
essary to ensure the basic level oI participation and
thus the reliability needed Ior a course-support sys-
tem.
First, we separated the user interIace Irom the basic
servent`s Iunctionality and moved all servents on a
server machine (see Eigure 1. right). We provided Ior
the users a downloadable Java-Swing interIace to al-
low them to log into their servents on the server. In
this way we could also control the access to the sys-
tem and limit it to include only the registered students
in the class. The shared resources by each servent. to-
gether with the servent resided on the server machine
and thus were always available independently oI
whether the user was currently logged in or not; since
the servents ran all the time. In this way. physically.
we had a server-based system. Logically. however. the
system was decentralized. since all the servents even
though residing on the same machine used the
Gnutella protocol to search Ior documents (web links
in our case). At any point they could be moved away
Irom the server to a diIIerent server. or could be dis-
tributed among various servers and even moved back
to the users` machines. as standard Gnutella clients
(Eigure 1. leIt).
Second. instead oI sharing the entire Iiles containing
the articles. as in the original Comtella. the users oI
this version shared only web-links. i.e. the URLs oI
articles that they Iound on-line. iust like the sharing oI
bookmarks in DAD |7|. The interIace allowed view-
ing oI the article in a browser directly by clicking on
18
the list oI search results. without the need oI
downloading and sharing the link (see Eigure 2).
The categories used to annotate the bookmarks corre-
sponded to the main themes oI the class curriculum
and textbook chapters. There was no hierarchy; anno-
tating oI shared web links and searching by theme was
straightIorward. Each theme was covered in one
week. with the exception oI theme 6 (Computer Crime
and Security). on which three weeks were devoted
with one week oI spring-break in-between.
Third. the Comtella interIace was modiIied to allow
users to rate and comment the articles that they shared.
The students were encouraged to download and share
web links that they Iound Irom others only iI they
have viewed and liked the article and wanted to com-
ment on it. The intention was to minimize the duplica-
tion oI resources among the peers. In this new version
oI Comtella. duplication oI resources was no longer
needed. since all servents were active all the time on
the server. In this way a resource (web link) shared by
a user was always available independently iI the user
was connected or not to the servent.
6. Motivating User Participation in Comtella
To ensure that there is a constant Ilux oI new re-
sources contributed to the system we applied two prin-
ciple strategies to motivate user participation:
Introducing hierarchical membership in the
community oI users. and
Visualization oI the community and the users`
activities.
The main idea oI the Iirst strategy is to stratiIy the user
community into diIIerent classes based on their par-
ticipation and give diIIerent privileges to the diIIerent
classes. e.g. diIIerent interIace options and a better
visibility in the community. This strategy is used in
Customer Relationship Management (CRM). Ior ex-
ample. by airlines or supermarket chains that reward
loyal customers with points accumulated on their club
membership cards and which can be exchanged in Iree
groceries or travel. Users who have achieved a higher
membership level Iear that they may loose it together
with the privileges associated with it. and act so as to
avoid this. e.g. tend to purchase their groceries in the
particular store. or Ily with particular airline |13|. In
Comtella users accumulate participation points and are
rewarded in terms oI better quality oI service (better
search options).
The metric Ior computing user participation takes into
account the Iollowing contribution categories: the
number oI resources (web links) that are newly intro-
duced in the system by the user. the number oI shared
resources by the user (also including those copied
Irom other users). the time the user spent on-line (i.e.
logged into the servent). the number oI ratings and
comments given by the user. The participation score is
computed as a weighted sum oI these Iactors
(normalized with respect to the total contribution by
the whole class in each contribution category).
Three levels oI membership are introduced: bronze.
silver and gold. The membership level oI each user is
re-calculated on a weekly basis. based on the level oI
the user`s participation score Irom the previous week.
The user can see his/her level visualized by a virtual
'card¨ in the upper-leIt corner oI the search screen
(see Eigure 2). II the user clicks on the card. he/she
can see a graphical representation oI his/her contribu-
tion level (several bars comparing each aspect oI par-
ticipation to the current top contributor in this aspect).
This representation suggests the activities in which the
user should engage to improve his/her membership
level (the open window in Eigure 2). Users with
higher membership level are rewarded with extended
search Iunctions. e.g. Iiltering out duplicate results or
articles that the user has already seen and sorting the
results alphabetically. by provider. by date oI sharing.
The second motivational strategy deployed in Com-
tella uses a visualization oI the community. Such visu-
alization creates social awareness and can stimulate
social comparison and competition among users |5|.
19
Figure 1. ModiIied architecture to ensure that servents run constantly and shared
Iiles are always available.
Figure 2: Search in Comtella and explanation oI the user`s member-
ship level.
20
and reward highly contributing users with a Ieeling oI
signiIicance in the community.
The visualization represents the users as nodes. whose
radius shows the level oI contribution oI the user (see
Eigure 3). Users who participate more actively in the
system are rewarded with better visibility: their nodes
are larger.
The colour oI the node shows the membership level
(gold. silver. bronze); the node is Iilled iI the user is
currently logged into his/her servent and empty iI the
user is not logged in.
Clicking on a node shows the web links shared by the
corresponding user. The user can choose diIIerent
views oI the community: a weekly view that shows the
contributions oI the users Ior a given week (category).
and particular Iorms oI contribution (see Eigure 3). In
this way. the user can view the current state oI the
community.
7. Experimental Results
In order to evaluate the motivational inIluence oI the
proposed motivational strategies. we compared the
level oI contributions oI the same group oI students
using two versions oI the Comtella system: Iirst a ver-
sion without and then a version with the motivational
strategies. The experiment took place during the
'Ethics and InIormation Technology¨ class oIIered in
the second term (January to April) oI 2003/2004 by
the Computer Science Department with thirty Iive (35)
registered students. We introduced the version imple-
menting the motivational strategies in the middle oI
the class (aIter the three weeks dedicated to theme 6).
The results showed that the number oI new shared
web links increased signiIicantly aIter the introduction
oI the motivational version The median contribution
number Ior the period beIore introduction oI the moti-
vational version was 51. while in the Iour weeks aIter
introducing the motivational version it increased to
154. i.e. 3 times. The peak oI contributions happened
two weeks aIter introducing the new version. AIter
Figure 3: Visualization oI the community with respect to the current member-
ship level oI the users
List of all the available
Sorting Criteria Bar ->
21
that peak. there was a decline with the level oI new
contributions going close to that beIore the new ver-
sion. Obviously. the motivational strategies were able
to stimulate user participation. at least in the short
term.
The quality oI shared web links decreased aIter intro-
ducing the motivational version. While beIore intro-
ducing the new version there were virtually no shared
articles that were unrelated to the current theme. aIter
introducing the motivational version there were 25
unrelated links shared in the Iirst two weeks and close
to 50 in the third week. Obviously. some users were
sharing links iust to boost their contribution numbers.
Eour oI the 35 users showed this behaviour. One ex-
treme case was the top contributor oI the class. who
shared 131 (13°) oI the 973 links submitted by all
students. oI which 40 (~30°) were irrelevant.
We observed that users clicked on the membership
card oIten to check their participation level. which
showed that they cared about it. The additional Iunc-
tions available to the Gold and Silver members were
used by approximately 65° oI the users who had ac-
cess to these Iunctions. The visualization was also
used oIten. though not in its Iull Iunctionality. The
most Irequently used view was the deIault one which
showed the size oI nodes based on the number oI the
new papers they brought in. Maybe due to this deIault
setting some oI the users concluded that this is the
most important Iorm oI participation (versus Ior exam-
ple. commenting or rating papers. or being on-line).
and tried to maximize it by 'cheating¨.
AIter the last week oI the experiment. the students
were asked to answer a detailed questionnaire about
their experience with Comtella. Thirty-one (31) stu-
dents responded to the questionnaire. Seventy percent
oI the users had positive reaction (¹1 or ¹2 on a scale
Irom minus 2 to plus 2) and sixty-seven percent said
that they would recommend the system to be used in
other classes.
When explaining this increase oI contributions we can
not ignore two Iacts: Iirst. that the motivational system
was used only Ior a relatively short time (Iour weeks)
and second that there were external Iactors in the ex-
periment. since it was taking place in a real class situa-
tion where students are exposed to various pressures.
motivations and time limitations. The eIIect oI novelty
is well documented in human-computer interaction
research. where signiIicant eIIects in user perIormance
can be observed aIter introducing a new interIace
item. which become insigniIicant in a longitudinal
study due to the Iact that the users become accustomed
to the interIace. Nevertheless we believe that there is
strong evidence that in our experiment the motiva-
tional strategies deployed in Comtella played the in-
tended role. This can be seen Irom the increase in the
amount oI attempted 'cheats¨. the usage oI the inter-
Iace Iunctions related to the rank and Irom the student
questionnaires.
8. Conclusions
We see two main contributions in our work. Eirst our
experience shows that P2P content sharing systems
can be applied successIully in small-scale applica-
tions. Ior example. in a research group or to support a
class that requires student involvement in locating
relevant resources and discussion. However. certain
modiIications and compromises are necessary with the
purist distributed P2P architecture in order to ensure a
critical mass oI users necessary Ior the Iunctioning oI
the system. These modiIications in our case involved a
physical centralization (moving the servents on one
dedicated machine) and applying incentive mecha-
nisms to motivate users to contribute resources.
Our experiment shows that applying persuasion strate-
gies is a promising way to stimulate participation and
active contributions by students. More studies and
studies with longer duration are needed to gain insight
in the dynamic process oI social motivation and there
will be speciIics depending on the complex interplay
oI Iactors Irom the context oI a particular application.
Generally. care should be taken. since every eIIective
incentive mechanism can motivate some people to
cheat. To prevent this. appropriate measures must be
22
taken. In the case oI Comtella. it is important that not
only quantity. but quality oI contribution is rewarded.
We are currently working on a mechanism allowing
users to peer-review and rate each others` contribu-
tions. on motivating users to rate contributions. and on
measures to police cheaters. i.e. invalid ratings. The
Slashdot strategy would be very appropriate to apply
in Comtella in combination with the existing two
strategies oI hierarchical memberships and community
visualization. It will help to motivate users to rate the
web-links provided by other users and in this way to
deal with the problem oI some users trying to cheat
their way to a higher membership levels by submitting
irrelevant web-links. It will also provide an attractive
reward Ior high-membership users in terms oI more
actual power (ability to rate up or down web links
contributed by other users) in the community. We are
currently testing a new Comtella version deploying
this strategy.
OI course. the introduction oI ratings may not solve
the problem. since users may Iind other ways to in-
crease their standing. e.g. by submitting Ialse ratings.
or by Iorming cliques. But iI there aren`t any attempts
to 'cheat¨ the system. this most likely shows that the
persuasion mechanism is not really working. We be-
lieve that a 'healthy¨ level oI cheating should be ex-
pected. though oI course. it should be discouraged. to
ensure Iairness and not compromise the attractiveness
oI the rewards Ior honest users.
More inIormation about Comtella. as well as a
downloadable version oI the servent is available on
the MADMUC Lab homepage at: http://
bistrica.usask.ca/madmuc/peer-motivation.htm
About the Authors
References
|1| Adar. E. & Huberman. B.A.. (2000). Eree Riding
on Gnutella. Available online at http://
www.Iirstmonday.dk/issues/issue5_10/adar/
|2| Baase. S. (2003) A GiIt oI Eire: Social. Legal. &
Ethical Issues Ior Computers & the Internet.
Prentice Hall.
|3| Bretzke H.. Vassileva J. (2003) Motivating Coop-
eration in Peer to Peer Networks. Proceedings
User Modeling UM03. Johnstown. PA. June 22-
26. Springer Verlag LNCS 2702. 2003. 218-227.
|4| Buragohain. C.. Agrawal. D.. Suri S. (2003) A
Game Theoretic Eramework Ior Incentives in
P2P Systems. Proc. oI the 3rd International Con-
Ierence on P2P Computing (P2P2003). Linkop-
ing Sweden.
|5| Cialdini R. (2001) InIluence: The Science oI Per-
suasion. ScientiIic American. Eebruary. 2001.
76-81.
Julita Vassileva is an asso-
ciate proIessor in Com-
puter Science at the Uni-
versity oI Saskatchewan.
Her interests are in user
modeling. advanced learn-
ing technologies. and user
issues in decentralized
peer-to-peer applications.
Ran Cheng. Lingling Sun
and Weidong Han are
Masters Students at the
Computer Science Depart-
ment studying use persua-
sion. community aware-
ness and visualization in
peer-to-peer networks.
23
[6j Comtella (2002) available to download Irom
http://bistrica.usask.ca/madmuc/peer-
motivation.htm
|7| Cordasco G.. Scarano V.. Vitolo C. (2004) A P2P
Distributed Adaptive Directory. Proceedings
Adaptive Hypermedia 2004. Springer LNCS.
|8| Gnutella (2000) available (accessed Aug 17. 2004)
at http://www.gnutella.com
|9| Golle P.. Leyton-Brown K.. Mironov I. (2001).
Incentives Ior Sharing in Peer-to-Peer Networks
Proceedings EC´01. October 12-17. 2001.
Tampa. Elorida. ACM press. 264-267.
|10| Johnson S (2002) Emergence: The Connected
Lives oI Ants. Cities and People.
|11| JTella (2000) available on-line at http://
www.iavaworld.com/iavaworld/iw-10-2000/iw-
1006-Iileshare-p1.html
|12| Shirky C (2003). Eame vs Eortune: Micropay-
ments and Eree Content. Eirst published Septem-
ber 5. 2003 on the "Networks. Economics. and
Culture" mailing list. available online at: http://
shirky.com/writings/Iame_vs_Iortune.html
|13| Nabi R. (2002) Discrete Emotions and Persuasion.
The Persuasion Handbook: Developments in
Theory and Practice. In J. Dillard & M. PIau.
Sage Publications. 289-308.
|14| Vassileva. J. (2002) Motivating Participation in
Peer to Peer Communities. Proceedings oI the
Workshop on Emergent Societies in the Agent
World. ESAW'02. Madrid. 16-17 September.
2002. Springer Verlag LNAI 2577. 141-155.
|15| Vassileva J (2004) Harnessing P2P Power in the
Classroom. Proceedings Intelligent Tutoring Sys-
tems. ITS`2004. Lester. J.; Vicari. R.; Paraguacu.
E. (Eds.). Lecture Notes in Computer Science
No. 3220
305-314.
24
Editor`s Note
In my last editor`s note. I talked about the JXTA technology. That was Iour months ago. Since then. I have
started to implement the Proiect Venezia-Gondola (Proiect V-G). a Peer-to-Peer Commerce proiect. (See that
article in the current issue.) The idea behind the proiect had occurred to me over one year ago.
I am planning Iollowing Ieatures.
1. Build a P2P based good and service exchange system. Eor example. a book exchange club.
2. Support various transaction models. including 'sale¨. 'auction¨. 'lending¨. 'reservation¨. 'negotiate¨.
3. Provide directory services. possibly using a hybrid P2P & centralized website approach.
I will be using JXTA technology because it allows me to tunnel through Iirewalls and proxies. Additionally
JXTA is supported by Sun Microsystems; I hope it will be closely aligned with enterprise Java technology. e.g.
(J2EE. Struts). I am planning to build JXTA connectors to databases on the server-side. I am envisioning a P2P
application that can become an alternative and be complimentary to Amazon and ebay.
The article submitted by Dr. Julita Vassileva is very interesting. It discusses Comtella which is a tool that al-
lows students and researchers to share inIormation and URLs. Comtella is like a giant 'whiteboard¨ that can
be used by many people simultaneously. Additionally. Comtella has 'memory¨ and behaves like a 'notepad¨
Ior the mass. It stores user inIormation on a server and allows sharing even when a user is oII-line. That tools
has a lot oI value.
Now. let me shiIt to a diIIerent topic. In the news. US congress is working on a bill that will 'eIIectively¨ ban
the P2P technology. It is called the 'Inducement Act¨. That act will make hardware manuIacturers and soIt-
ware developers liable Ior copyright inIringement. (See http://www.savetheipod.com/index1.php) Just imag-
ine. you and Xerox will be sued because you had photocopied your 1040 tax return. Apple can be sued because
someone saved his/her Iavorite song onto an Apple iPOD. HP will be liable because it makes scanners. and
Cannon should go to court because someone took a picture oI Mona Lisa. That act will severely limit a citi-
zen`s constitutional Ireedom and restrict Iuture technology innovation. (See http://www.savethe.org/bad.php
on why this legislation is really bad.) The recording industry and Hollywood are lobbying the congress really
hard to pass this bill. They want this law to protect their existing business models. As a consumer. we don`t
want this. Please tell your congressmen and senators to vote against this legislation # S2560. (You can
voice your opinion through the above URLs.)
25
3ob Posting
Company - Netkey ( http://www.netkey.com )
Senior Engineer, Communications
Role and Responsibilities
Responsible Ior the delivery oI a communications inIrastructure between Netkey's enterprise management server. and a network
oI selI-service devices deployed nationwide.
Design. modiIy. develop. write and implement soItware programming applications. Support and/or install soItware applications.
Participate in the testing process through test review and analysis. test witnessing and certiIication oI soItware. Provide technical
support to proiect team members.
Required Experience
Java (min 4 years). C¹¹ (min 5 years). JXTA. J2ME. XML. Web Services
Middleware. data compression. guaranteed delivery. recoverability. peer to peer networks. network protocols development. Mul-
tithreading.
Recommended Experience
Knowledge oI Iirewall and routers standards
NDIS and transport protocol drivers
SMS or other enterprise management experience
Send resumes to: lprice(netkey.com
Senior Engineer, Client
Role and Responsibilities
Responsible Ior creating a portable runtime environment Ior running kiosk applications. Initial support will be Windows and
Linux and eventually WinCE. PALM and embedded devices.
Design. modiIy. develop. write and implement soItware programming applications. Support and/or install soItware applications.
Participate in the testing process through test review and analysis. test witnessing and certiIication oI soItware. Provide technical
support to proiect team members.
Required Experience
Java. J2ME. Swing. JNI. C¹¹. MEC. ATL. COM. ActiveX.
IE Browser Control and/or Mozilla Geiko engine. Embedded Media Players.
Multithreading. Linux kernel development. X Windows Window Manager development. Windows Shell Extensions. Windows
Device Drivers.
Requires a bachelor's degree in a related area and 6-8 years oI experience in the Iield. Eamiliar with a variety oI the Iield's con-
cepts. practices. and procedures.
Recommended Experience
Handheld (WinCE. PALM) GUI experience.
Retail experience. speciIically POS systems.
Send resumes to: lprice(netkey.com
Jaruary. 2OO5
Content for 3anuary, 2005 Issue
Editor-in-ChieI: Raymond Gao (raygao(comcast.net)
Contributing Editors: Jaime Lloret (illoret(dcom.upv.es)
Reviewers: Daniel Brookshier (turbogeek(cluck.com)
Luca Caviglione (cvgl(mac.com)
Ian Taylor (I.J.Taylor(cs.cardiII.ac.uk)
Julita Vassileva ( iiv(cs.usask.ca )
P2P Journal is currently accepting articles Ior upcoming issues.
Copyright © 2005: Unless with explicit written permission Irom P2P Journal. no part oI this iournal may be recycled or re-
produced in whole or parts.
Cover Image: "St. Basil`s Cathedral. Moscow". A photo taken by Raymond Gao. September. 2004
(Additionally. we have a "call Ior the cover image" Ior upcoming issues oI P2PJ. Submit your artwork to raygao(comcast.net.)
1
Interconnecting Unstructured P2P File Sharing Networks
By Jaime Lloret
This article describes a novel structured interconnection system that works over
multiple unstructured P2P Iile sharing networks and provides additional manage-
ment Ieatures.
16
Editor`s Note
17
The Dagstuhl Conference
1he theme of the upcoming issue is on 1X1A and Web-Services
18
Book Review- From P2P to Web Services and Grids, Peers in a Client/Server World
Editor`s Note
It has been several months since the last issue oI P2PJ was published online. During these times. several inter-
esting things have happened. In October. 2004. I attended the Dagstuhl conIerence (read next page).
Right now. I am running Ior a 'board oI director¨ position with the Proiect JXTA (http://www.ixta.org) The
election is scheduled to begin on January 29. 2005. The board member position is Ior one year term.
I hope to take on Iollowing responsibilities when I am elected.
1. Stable and tight code bases Ior JXTA .
2. Clear documentation. including APIs. programmer`s guide. and tutorials.
3. Increase JXTA awareness in the enterprise computing environment.
4. Improve interoperability between JXTA with other platIorms. e.g. web-services. Gnutella. Bit-Torrent.
5. Better career prospect Ior people with JXTA skills. It will be nice to build a iob marketplace Ior JXTA-
skilled proIessionals. Good paying iobs and exciting proiects are good things Ior the JXTA community.
6. Last. reach out to all JXTA community members and to address their concerns.
And. I need your support.
The voting process is:
1. Open a Iree JXTA user account at
http://ixta.org
and register your e-mail account.
2. Use that e-mail account to send an e-mail to
boardvote(ixta.org
with subiect "JXTA.ORG 2005" indicating who you are voting
and your JXTA username. (See the Iollowing web page)
http://www.ixta.org/community/voting/election2004.html
The election schedule is as Iollows.
>> Eriday. January 28. 1 pm PST: Polls open Ior voting
>> Monday. Eebruary 13. midnight: Polls close Ior voting
>> Wednesday. Eebruary 15: Election results announced
During my Iree time. I also read Ian Taylor`s new book. titled 'Erom P2P to Web Services and Grids. Peers in
a Client/Server World¨. It is a well written book. (See attached book review).
Einally. I am thinking about moving P2P Journal to a Wikibased Iormat Ior publication. The pro-argument
will be increased interactivity Ior the iournal`s readers. Readers can write their comments directly to an article.
Wiki-based publishing will also mean that contents will be easily picked up by search engines. On the other
hand. we will loss the nicely organized Iormat and the iournal`s cover associated with using the PDE Iile. I
would like to hear what are my readers inputs. (raygao(comcast.net) The Creative Common license scheme
(http://creativecommons.org/) is also being reviewed.
16
The Dagstuhl Conference
In the October. 2004. I attended the Dagstuhl Seminar in Germany. (http://www.dagstuhl.de) It was a small
academic seminar held in Schloss (Castle) Dagstuhl. in the Sar-Lor-Lux region (Saarland. Lorraine. and Lux-
emborg). The conIerence receives Iunding Irom the State oI Saarland. Germany. This seminar was called
'Service Management and SelI-Organization in IP-based Networks¨. It had around 40 participants. Maiority oI
the attendees are Irom universities. e.g. Switzerland. Germany. England. USA. etc. There were individual pres-
entations as well as group discussions. Presentation topics ranged Irom the Iirewall. to the biology inspired
computer networks. to the mapping oI P2P network distance vectors. to the mobile IP service. etc. Presenta-
tions were either research results or proiect plans Ior Iuture research.
The conIerence environment was quite nice. Attendees stayed onsite and had individual rooms. One interesting
note is that those rooms don`t have keys Ior locking Irom the outside. However. a person can lock the room
Irom inside Ior privacy in night. There is a nice library that opens 24 hours. The library has a good selection oI
computer books. ranging Irom Java. to database. to numeric analysis. to HTML. and to web technologies. Ad-
ditionally. there was a computer lab with Internet access. There are several SunRay machines in the computer
lab. In the residence area. there is a billiard table. That makes it Ieels like a small college campus. The town oI
Wadern is nearby. I visited that town one night and had dinner over there.
I am attaching here a group photo Irom that conIerence.
17
Book Review
Book Title - From P2P to Web Services and Grids, Peers in a Client/Server World
Book Author - Ian Taylor
Review Date - 11/22/2004
I recently read Ian Taylor`s book. 'Erom P2P to Web Services and Grids. Peers in a Client/Server World¨. I
became acquainted with Ian when I read his online classes note on P2P and distributed systems several months
back. Later. Ian asked me to review his book. This new book is based on those class notes. The book includes
new material and has expanded discussion on several technologies. Eor example. the book has added chapters
on Globus / OGSA. Ereenet. and web services. and gives extended looks on scalability and security.
The book has Iour parts. I - Distributed Environments. II Middleware. Applications and Supporting Tech-
nologies. III Middleware Deployment. and IV Erom Web Services to Euture Grids. The Part I Iunctions as
an orientation. It talks about what are P2P. web services. and grid computing technologies. It covers the con-
cept. the history. the social impact. and the applications. The Part II explores several well-known P2P and dis-
tributed computing technologies. e.g. Jini. Gnutella. Ereenet. and JXTA. It also gives in-depth look at several
important concerns. e.g. scalability and security. The chapter on security is well written and clearly explains
what are cryptography. hashing. and digital signature. Additionally. the chapter on Ereenet clearly explains
how Ereenet works and organizes content. The author has eIIectively used analogy to describe key concepts.
'virtual organization¨. storing and addressing contents. network topology. etc. The Part III includes chapters
on several demo applications. Due to my busy schedule. I did not have time to download and build those soIt-
ware applications. The Part IV is a section dedicated to Grid technologies. particularly on Globus. This section
expands the discussion Irom chapter 4.
As the editor-in-chieI oI P2P Journal. I have Iound reading this book was well worth my time. It is concise and
clear. The book uses unambiguous language to cover some abstract and diIIicult to grasp concepts. It can be a
useIul book Ior people who want to understand those technologies. whether as a general purpose or as a hand-
book.
18