Roger Clarke's Overview of P2P
Roger
Clarke
**
Version of 1 November 2004
©
Xamax Consultancy Pty Ltd, 2004
Available under an AEShareNet 
licence
This document is at http://www.anu.edu.au/people/Roger.Clarke/EC/P2POview.html
1.
Introduction
The concept of peer-to-peer architecture or P2P has been 'in the air' for
some time. The concept is rich, and the scope for misleading explanations and
confusion is considerable. This document explains the origins and nature of
P2P, in an endeavour to overcome the wide array of misunderstandings that
exist, and to assist in better-informed discussions of P2P technologies, and of
their strategic and policy implications.
2.
The Context
The number of processors connected via the Internet is now vast. Some of
them are powerful machines designed to run software that provides services to
many people and devices, and to manage data that is accessible by many people
and devices.
Most, on the other hand, are devices that service the needs of one user at a
time, or users in one very small location. No fully satisfactory term exists
to refer to such devices, but 'PC' and 'workstation' have been in common usage
for a considerable period of time. Meanwhile, the diversity of connected
devices is increasing. Networked playstations are becoming common, handheld
devices and even appliances (in the sense of 'white goods' such as
refrigerators) are increasingly Internet-connected, and computers are being
released as home entertainment centres for the local rendering of audio and
video, extracted from CD/DVD, broadcast and webcast. These devices may support
multiple processes, different users at different times, and even multiple users
at the same time, and they may be connected physically or by wireless means.
The capacity of these devices is now substantial, both in terms of processing
and storage. This has not gone unnoticed. A variety of initiatives have
sought to harness this 'power at the edge of the net'. This can be done on a
hierarchical basis, managed centrally; but it may also be done on a
collaborative basis among the users or devices themselves, with no
centralisation, and only a limited amount of coordination from a central
location.
3.
The Predecessor Architectures
During their first two decades, roughly the 1940s and 1950s, computers were
very large devices that had no connection with other devices. The means
whereby data was input to and output from computers started very primitively
but gradually became more sophisticated. One technique was to use 'telex
machines' or 'tele-types', which comprised a typewriter keyboard for input, and
computer control over the printing facility for output. The first networks
emerged in the 1960s, to connect remote 'terminals' of this kind to central
computers.
These 'dumb terminals' had no programmable components. The topology of such a
system resembled a star, with a computer at the centre or hub, and each
terminal was connected to it by means of a cable. The architecture was
referred to as 'master-slave', because the central device had
all intelligence and power, and the remote devices did its bidding. See
Exhibit 1.
During the 1970s, the original terminals were augmented with and then replaced
by 'glass tele-types'. These still comprised keyboards for input, but instead
of a printing device for output, they used cathode ray-tubes (CRTs) - the same
technology used in television sets from the 1930s until about 2000. These
'visual display units (VDUs)' initially contained no programmability, and hence
the network topology and architecture remained essentially the same.
During the 1970s and 1980s, processing power was added to VDUs, initially at a
deep level to provide greater flexibility for the engineers installing and
configuring them, and later to provide application programmers with some
limited capacity to run part of the application on the terminal.
Meanwhile, the miniaturisation of processors had resulted in the explosion of
personal computers (PCs), commencing in the mid-1970s, and picking up pace
during the early 1980s. From very early in this phase, PCs were being used in
conjunction with modems and dial-up lines for inter-PC communications. By the
late 1980s, PCs were readily connected to the large computers that dominated
the processing of business and government data.
The patterns were now very different. A great deal of processing was now being
performed on the remote devices. A new architecture emerged that was dubbed
'client-server'. A client (software running on one device,
such as a user's email-package or a web-browser) requested a service from a
server (software running on another device, such as an email-host or a
web-server). The server was generally running on a large central device
(typically a 'mainframe' computer), and the client was generally running on a
small remote PC. The nature of coordination and control had changed: the
masters had become servers, and the slaves had become clients. See Exhibits 2a
and 2b.
During the course of the 1990s, master-slave architectures became the
exception. Client-server architecture became the mainstream, and remains so in
the mid-2000s. Many of the most familiar working-tools currently operate in
this way, including the downloading of emails from one's mailbox, and the use
of a browser to access web-pages. Indeed, client-server architectures have
been so dominant that many people who became computer users during the last two
decades simply assume that this is how computers collaborate, and do not
appreciate that alternative architectures exist and more could be conceived.
4.
Deficiencies of the Predecessor Architectures
There are some significant problems evident with client-server architecture,
however. These include:
- lack of robustness: services are fragile, because, in
the pure form of client-server architecture, the availability of a service is
dependent on:
- a single server running on a single device; and
- a small number of communication links that connect that device out to the
remote devices, resulting in a bottleneck;
- lack of resilience: services, once broken, cannot be
recovered quickly, because they remain unavailable until the relevant device
and/or network has been returned to a workable state;
- lack of scalability: as resources supporting a
client-server scheme are expanded, the number of users that can be supported
does not grow as quickly. Hence very large schemes are very expensive;
- incapacity to service levels of demand that are very high
relative to the processor and network resources. Peaks may arise on a daily,
monthly or yearly cycle, as a result of external conditions such as bad
weather, or as a result of an entertainment, marketing or sporting event;
- vulnerability to attack, especially denial of service,
but also masquerade and data pollution.
A variety of refinements have been implemented in order to address these
deficiencies. Several of these depend on applications of the redundancy
principle, i.e. the provision of more than the minimum necessary resources, and
the arrangement of the resources in such a manner that the excess caters for
temporary failures. For example, multi-processor configurations such as
server-farms reduce the fragility of service that arises from device downtime;
and replication, mirroring and caching reduce the fragility of service that
arises from sub-network outages and congestion.
Backup and recovery techniques, including business continuity planning and
warm-site and hot-site services, improve resilience by shortening the time that
a service is unavailable following a major interruption. Various approaches
have been adopted to address the substantial security problems inherent in
current technologies, including 'thin-clients' that are stripped of some of the
capabilities of normal PC/workstations, less because of cost than for the
reduction in vulnerability that may be able to be achieved.
5.
Potential Applications for a New Architecture
The refinements do not, however, address the fundamental problems. The
growth in the power of computing at the edge of the Internet has created an
opportunity for an alternative architecture that would avoid many of the
deficiencies, or enable them to be more readily overcome.
The value of such an architecture may be high for some kinds of application,
but not for others. Characteristics of applications for which
the new architecture would be particularly attractive include those for which:
- demand is high relative to the power of individual
processor-clusters and sub-networks, whether for an extended period of time, or
just brief periods;
- demand is widespread rather than arising within close
proximity to individual processors and sub-networks. (The sense in which the
term 'proximity' is used may be related to terrestrial geography or
network-topology).
Some of the application scenarios relate to processing
services, such as:
- searching data for patterns (e.g. SETI@home);
- testing a set of possible keys as part of a collaborative key-discovery
process (e.g. EFF's DES cracking project);
- large-scale, brute-force numerical methods (e.g. meteorology, and fluid
dynamics experiments);
- multi-player networked gaming;
- message transfer, for conferencing/chat/instant messaging, and for
cooperative publishing.
Many more of the application scenarios relate to digital
objects, such as:
- software fixes/patches, and data such as virus signatures. Objects with
significant security implications need to be accessed very quickly by many
devices, and hence generate highly peaked activity;
- software releases, access to which may be highly-peaked for functional
reasons, or because of popularity or fashion;
- announcements of many different kinds, including technical information,
business information, entertainment, sports results, promotional messages and
advertisements;
- news reports, including not only those generated by news organisations,
but also informal traffic emanating from members of the public at the scene of
an event such as a concert, product-launch, sports tournament, demonstration,
or crime-scene;
- emergency-services traffic;
- data backup and recovery;
- learning materials, variously in text, image, sound and video formats;
- entertainment materials, variously in text, image, sound and video formats;
- games data, e.g. scenes and battle configuations;
- message archival, for conferencing/chat/instant messaging, and for
cooperative publishing.
Some applications are targetted at consumers, and others at business users.
Considerable media attention has been paid to the sharing among consumer-users
of entertainment materials, particularly in the form of recorded music,
primarily in MP3 format, and increasingly video as well. These kinds of files
are known to constitute a very large proportion of the total volume of
transmissions over P2P networks, and a significant proportion of those
file-transfers is known to be being performed in breach of copyright law. The
majority of the application scenarios listed above are, however, already
operational, and hence, however large it might be, copyright-infringing
file-sharing needs to be appreciated as one form of P2P use among many.
6.
The Long History of P2P Architecture
The presumption is commonly made that P2P is a new idea. That is not the
case. It was in use as early as the 1970s, an era that, as discussed above,
was still dominated by master-slave architecture. Key examples include:
- ARPANET services, established in 1969, and which evolved into the Internet
in 1983, many of which treated participating nodes as peers;
- message transfer agents, operational from 1972, such as those implementing
the SMTP protocol for the forwarding of email-messages, which both perform
server functions for clients, and act as a client by issuing requests to other
nodes. (The downloading of email from one's mailbox, on the other hand, is a
classic example of an application of client-server architecture);
-
USENET,
now called Netnews, which passes messages among participating devices, and was
implemented in 1979 independently of the Internet;
-
FidoNet,
which was a file and message transport system used by bulletin board systems
from 1984 onwards, over dial-up lines, before the availability of the Internet
to the general public;
- the domain name system (DNS), implemented in 1984 as a single piece of
software comprising a server that accepts requests for conversion of
domain-names into IP-addresses, and a client that passes requests to other
servers. (The DNS relies on some centralised elements, and the
distributed
DNS (DDNS) project has been investigating conversion to something closer to
a 'pure P2P architecture').
Appreciation of the principles underlying P2P, and of their general
applicability, increased substantially during the second half of the 1990s,
with the result that many experiments were conducted and many services were
launched. Napster attracted huge volumes of traffic between 1998 and 2001.
Since its demise due to the provider's inability to comply with court orders,
other similar services have experienced similarly dramatic growth rates, most
notably Kazaa. In late 2004, there are
scores
of active implementations.
7.
Fundamental Characteristics of P2P Architecture
The following are the characteristics of P2P architecture that need to be
satisfied in order for it to offer an alternative that overcomes a significant
proportion of the deficiencies of predecessor architectures:
- many devices perform server-functions (perhaps hundreds,
perhaps hundreds of thousands, depending on the nature of the application and
the volume of use). This is the fundamental requirement, in order to overcome
the dependency and bottleneck deficiencies. In principle, any available
general-purpose computing device could be used, however connected. In
practice, each device needs to have significant residual processing capacity
after the user's current processes are performed; and the connections need to
have sufficient capacity and to be persistent over a sufficiently long period
of time to justify the overheads involved in establishing and disestablishing a
server. All of the terms are relative; for example some applications may
require upper-end PCs, broadband connections and hours of availability;
whereas others function effectively on smaller PCs, narrow-bandwidth dial-up
lines, and minutes of availability;
- any device that performs server-functions is able to perform all
server-functions. This is critical in order to ensure that the
dependency and bottlenecking problems are genuinely addressed rather than
merely being masked. In practice, many examples of P2P networks have
compromised this to some extent. In the most limiting case, it is important
that no server function be performed by only one or a few devices, and that
those devices not be on the same sub-network. This is, however, subject to
qualification in two particular cases:
- when a network is launched, there may be initially only one server; and
- when a digital object is first published, it is likely that only one
server will initially have access to it;
- any device that is acting as a client is able to find one or more
devices that are performing server-functions;
- servers assist clients to find more servers, in the event
that the client's request cannot be satisfied by the first server that it
contacts;
- the devices are connected in such a manner that bottlenecks and
susceptibility to single points-of-failure are avoided. That implies
many multiply-connected devices rather than simple
hierarchies.
Examples of the kinds of topologies that result are represented graphically
in Exhibits 3a and 3b.
An array of
definitions
of P2P is available, ranging from populist to reasonably formal, and from
accurate via incomplete to misleading and even seriously misleading. A working
definition is proposed as follows:
peer-to-peer (P2P) is a network architecture in which nodes are relatively
equal, in the sense that each node is in principle capable of performing each
of the functions necessary to support the network, and in practice many nodes
do perform many of the functions
In a 'pure P2P architecture', all functions and all relevant digital
objects are distributed across many nodes, such that no node is
critical to the network's operation; hence no node can exercise control over
the network. Examples of these exist (such as USENET, Fidonet, Freenet and the
original Gnutella).
Most instances of P2P architecture involve some degree of compromise of these
requirements. Most commonly, the content or services may be fully
distributed, but the index may be substantially distributed but not fully
distributed (as is the case with FastTrack and the later version of
Gnutella).
Alternatively, the index may be heirarchically structured (as in the DNS), or
even centralised (as was the case with Napster, and is with BitTorrent).
Napster and BitTorrent can be described as having a 'hybrid architecture', in
that the index is accessed in client-server mode, whereas the digital objects
are transferred directly between peers. If a very relaxed interpretation of
'P2P' is permitted, then at the extremity it corresponds to client-server
architecture; but most usages of the term 'P2P' preclude that
interpretation.
A literature on the history and concept of P2P is emergent. Some useful
sources,
academic
sites and links to
conferences
are provided below.
It is useful to compare and contrast P2P architecture with the parallel
research domain called 'grid computing'. This is a means whereby available
processing resources can be located, used and coordinated; whereas P2P
encompasses both processing and data resources. Grid computing also differs
from P2P in that it is a largely pragmatic engineering effort, rather than a
scientifically designed architecture. See, for example,
Ledlie
et al. (2003).
8.
Practical Requirements of Effective P2P Architecture
For P2P architecture to be implemented, it is dependent on infrastructure,
and collaboration among the infrastructural elements. The necessary elements
include:
- a physical network of appropriate reach and scale. The
open public Internet is a network of networks, and provides a very widely
available infrastructure over which P2P services can be deployed. Although the
contemporary focus is very much on the Internet, other networks can be used,
such as closed corporate networks (whether genuine 'intranets' running TCP/IP,
or running some other suite of protocols), local area networks (LANs), or
regional networks;
- protocols for communication among nodes. A number of
mature and effective protocols exist, more are in development, and a
considerable amount of research is being conducted into their design features;
- naming conventions. Nodes need to be identified, e.g.
using a socket identifier (i.e. IP-address and port-number), or by some
application-specific naming mechanism. Digital objects also need to be
identified. A common approach is to generate a fixed-length hash of the
contents of the file, and use that as the object's identifier;
- metadata. Descriptive information about the processing
service or digital object may be provided or generated, e.g. originator,
publisher, title, date, version;
- search mechanisms. A means is needed to locate target
processing services and digital objects. Many current schemes rely on queries
to multiple or successive servers until one or more instances of the target are
found. A number of P2P architectures are built around a distributed hash table
(DHT -
Xie
2003);
- software that implements the necessary client and server
functions. Many packages exist, and more are in development.
Catalogues
of P2P protocols and applications are provided below. A considerable
amount of research is being conducted. Links to a selection of
academic
sites are provided below;
- the acquisition of participating
devices. There are various ways in which devices might be caused to
be contributors to a P2P network. These include:
- central provision, e.g. a school or university, or a school system or
federation of organisations, might make all or a selection of their devices
available;
- volunteer home-users, e.g.
SETI@home
depends on individual users donating the spare time on their machines to the
project. (Note: SETI@home is only weakly conformant with the requirements for
a P2P architecture, and lists variously include and exclude it, depending on
the threshholds of acceptability applied by the particular list-owner);
- all devices running clients that wish to use the service, or a sufficient
sub-set of them. This is currently the most common approach. It is
intuitively appealing to use a dispersed sub-set of the better-endowed among
the available devices, but various selection criteria are applied. Devices are
commonly used consensually, although possibly with weakly-implied consent
rather than conscious, fully-informed and freely-given consent. But there is
nothing inherent in P2P that ensures that participation is consensual; it
depends on the particular design, and on the security features and
vulnerabilities of each node.
Practical implementations of P2P architectures include features to encourage
the availability of devices to perform as servers, and to discourage devices
from 'free-riding' or 'over-grazing' the 'commons' that is intrinsic to the
architecture. In many cases, participation is more likely to be achieved if
the load on the server only lasts for a short period of time, during which the
user is unlikely to adopt measures to cause the server component to cease
operating. As a result, many P2P schemes involve ephemeral servers, a highly
dynamic network topology, and highly volatile metadata.
9.
Areas of Superiority of P2P Architecture Over Predecessors
In comparison with the deficiencies of master-slave and client-server
architecture noted
above,
P2P architecture has the following characteristics:
- much-reduced dependence on individual devices and
sub-networks. This is subject to qualifications depending on the
details of the design, and on such factors as the stage of maturation of the
network, the extent of participation, and the age and popularity of the
particular digital object;
- improved resilience. There is no single-copy ('Library
of Alexandria') problem, because many copies of objects exist; and some level
of service resumes as soon as any of the servers, or any part of the network,
becomes available. This is subject to qualifications, as for the previous
characteristic;
- much-improved scalability. The capacity to service users
grows close to proportionally to the number of users. This is because the
users themselves are providing resources;
- much-improved ability to service highly-peaked demand.
This is because the load is widely dispersed both on devices and on
sub-networks;
- resistance to denial of service attacks. This is a
result of the wide dispersion of servers, and the consequential need for an
attacker to mount multiple, parallel, coordinated attacks in order to achieve
their objective.
10.
Issues Arising in Relation to P2P Architectures
There are, of course, aspects of P2P architectures that fall short of
requirements. Of the deficiencies of predecessor architectures noted earlier,
they fail to escape the following deficiencies:
- vulnerability to masquerade attacks, such as falsified
digital objects and services that purport to be known ones; and
- vulnerability to pollution attacks, such
as adapted versions of known digital objects or services.
In the absence of countermeasures, a P2P network may generally be more
vulnerable to these kinds of attacks than is a client-server network. They
are, however, capable of being addressed by similar techniques to those needed
in client-server architectures (in particular content hashes and digital
signatures).
In addition, a range of new issues arise, including the following:
- master-slave and client-server architectures embody determinism, whereas
P2P architectures are probabilistic, and feature unpredictability of,
and volatility in, the locations of processing services and digital
objects. Implications of this include the following:
- attempts to visit or revisit old addresses for services and digital
objects may well not be successful;
- trust based on repetitive dealings with a particular organisation is
difficult to sustain;
- the lack of central control has the corollary that there
are no chokepoints (in the case of 'pure P2P architecture') or at least fewer
chokepoints (in the many cases of somewhat compromised and hybrid
architectures). This has two further implications:
- P2P architectures present serious challenges to the imposition of
authority on applications, digital objects and users. In effect, the
removal of a device as a result of the execution of a warrant or injunction is
indistinguishable from other forms of denial of service attack;
- P2P architectures feature a reduction in user
accountability, because people perceive themselves to be, and may well
be, difficult to trace and identify. Although traceability and hence the
possibility of retribution are not the only factors involved in control over
anti-social behaviour, they are important factors. It is therefore to be
expected that P2P will be used by some people for purposes that breach the laws
of various jurisdictions, particularly censorship and copyright;
- new security challenges arise. Many of these are capable
of being addressed, but vulnerabilities exist until learning has taken place,
appropriate features have been designed and implemented, and new versions of
software have been widely deployed;
- in some circumstances, surreptitious enlistment of
devices into a P2P network may be feasible:
- without the informed and freely-given consent of the person responsible
for the device;
- without any kind of consent; and even
- without the person's knowledge;
- the embedment of various kinds of
malware
into P2P software is feasible, in order to, for example, extract
personal data from the device, or modify or delete data or software on the
device;
- the users of P2P networks can apply them to the reticulation of
digital objects in breach of the wishes of persons that have interests in
them, such as desire for the information to remain secret;
- the users of P2P networks can apply them to the reticulation of
digital objects in breach of censorship laws; and
- the users of P2P networks can apply them to the reticulation of
digital objects in breach of the rights of the persons that own copyright in
them.
11.
Conclusion
P2P architecture differs substantially from its predecessors. There are
many applications already in operation, and they have demonstrated that the
theoretical technical advantages claimed for them are achievable. But they
bring with them new challenges.
When evaluations are undertaken of P2P architecture, infrastructure and
services, it is important that the opportunities and the issues be appreciated
in context rather than in isolation, and that the positives and negatives be
considered together.
Resources
Definitions
The following three definitions express current usage effectively:
- "any network that does not have fixed clients and servers, but a number of
peer nodes that function as both clients and servers to the other nodes on the
network. This model of network arrangement is contrasted with the client-server
model. Any node is able to initiate or complete any supported transaction"
(Wikipedia)
- "A P2P networking application exploits the resources in users' computers -
storage, content, CPU cycles, and human presence - and has significant autonomy
from central servers. Typically, the users' computers (i.e. the peers) have
intermittent connectivity" (Kurose J.F. & Ross K.W. 'Computer Networking:
A Top-Down Approach Featuring the Internet' Pearson Education, 2005, pp. 58-59)
- "Peer-to-peer is a communications model in which each party has the same
capabilities and either party can initiate a communication session. Other
models with which it might be contrasted include the client/server model and
the master/slave model. In some cases, peer-to-peer communications is
implemented by giving each communication node both server and client
capabilities. In recent usage, peer-to-peer has come to describe applications
in which users can use the Internet to exchange files with each other directly
or through a mediating server"
(TechTarget)
A small selection of other definitions is provided for completeness:
- "a decentralised, dynamic resource network, composed of ad hoc,
heterogeneous peers, who join and leave at will, without restriction"
(Loban
2004)
- "P2P is a class of applications that takes advantage of resources --
storage, cycles, content, human presence -- available at the edges of the
Internet. Because accessing these decentralized resources means operating in an
environment of unstable connectivity and unpredictable IP addresses, P2P nodes
must operate outside the DNS system and have significant or total autonomy from
central servers"
(Shirky
2000)
- "direct communication or collaboration (mostly file-sharing) between
computers, where none are simply client or server, but all machines are equals
- peers [and] Systems whereby ordinary nodes - in particular desktop PCs - at
the edge of a network are given substantial independence, and which handle the
variable addresses of these nodes. What makes P2P unique is not two nodes
talking to each other as equals, but the type and (virtual) location of the
nodes. Ordinary PCs, previously little more than web-page viewers, become
active participants in the Internet, despite their lack of fixed IP addresses"
(Brosnan
et al. 2002)
- "a type of network in which each workstation has equivalent capabilities
and responsibilities. This differs from client/server architectures, in which
some computers are dedicated to serving the others"
(Webopedia)
- "Peer-to-peer (P2P) systems are distributed systems without any
centralized control or hierarchical organization, where the software running at
each node is equivalent in functionality"
(Liben-Nowell
et al. 2002)
- "person-to-person software that permits direct Internet-based
communication or collaboration between two or more personal computers while
bypassing centralized servers"
(McGraw
Hill Online Learning Center)
- in
FOLDOC,
the only definition provided is from 1994, and relates to a more technical
usage within layered communications protocols
Useful
Sources
- Anderson R. (1997)
'The
Eternity Service' Cambridge University Computer Laboratory, June 1997
- Blackmore N. (2004)
'Peer-To-Peer
Filesharing Networks: The Legal and Technological Challenges for Copyright
Owners' N.S.W. Society for Computers and the Law 55 (March 2004)
- Clarke I., Sandberg O., Wiley B. & Hong T.W. (2000)
'Freenet:
A Distributed Anonymous Information Storage and Retrieval System' Lecture
Notes in Computer Science
- Felter W. (2002) 'Design Choices in P2P Infrastructure' IBM Austin
Research Laboratory (a
slide-set)
- Gummadi K. P., Dunn R. J., Saroiu S., Gribble S. D., Levy H. M. &
Zahorjan J. (2003) 'Measurement, Modeling, and Analysis of a Peer-to-Peer
File-Sharing Workload' Proc. 19th ACM Symposium on Operating Systems
Principles (SOSP-19), October 2003
- Kurose J.F. & Ross K.W. 'Computer Networking: A Top-Down Approach
Featuring the Internet' Pearson Education, 2005, pp. 58-59, 75-78 and 136-145
- Ledlie J., Schneidman J., Seltzer M. & Huth J. (2003)
'Scooped,
again' Proc. 2nd International Workshop on Peer-to-Peer Systems (IPTPS '03)
- Leibowitz N., Ripeanu M. & Wierzbicki A. (2003) 'Deconstructing the
Kazaa Network' 3rd IEEE Workshop on Internet Applications (WIAPP'03), 2003,
Santa Clara, CA
- Liang J., Kumar R. & Ross K.W. (2004)
'Understanding
KaZaA' Working Paper,2004
- Loban B. (2004)
'Between
rhizomes and trees: P2P information systems' First Monday 9, 10 (October
2004)
- Oram A, (Ed.) 'Peer-to-Peer: Harnessing the Power of Disruptive
Technologies'
O'Reilly,
2001, including
Chapter
1: A Network of Peers - Peer-to-Peer Models Through the History of the
Internet
- Preston A. (2002) 'Peer-to-peer: an overview of a disruptive technology',
Internet2 Peer-toPeer Working Group (a
PowerPoint
slide-set)
- Ross K.W. (2004)
'Recommended
Reading in P2P Networking Theory' Catalogue, 2004
- Ross K.W. & Rubenstein D. (2004) 'P2P Systems'
Tutorial
Slide-set, 2004
- von Lohmann F. (2003)
'Peer-to-Peer
File Sharing and Copyright Law: A Primer for Developers' Proc. 2nd
International Workshop on Peer-to-Peer Systems (IPTPS '03)
-
Wikipedia,
including the articles on P2P, Kazaa, Hash_function and UUHash
- Woody T. (2003)
'The
Race to Kill Kazaa' Wired 11.02 (February 2003)
- Xie M. (2003)
'P2P
Systems Based on Distributed Hash Table' Department of Computer Science,
University of Ottawa
Academic
Sites
-
Berkeley
- the Tapestry project in the University of California, Berkeley's Department
of Computer Science
-
CMU
- Peer-to-Peer Content Distribution at Carnegie-Mellon University Department of
Computer Science
-
Internet2
Peer-to-Peer Working Group
-
MIT
- the CHORD project of the MIT Laboratory of Computer Science
-
PSU
- the LionShare project at Pennsylvania State University
Conferences
Catalogues
of P2P Applications
Acknowledgements
I've developed my understanding of P2P through research and teaching since
2000. I've drawn on many published sources in developing this overview, and
have benefited from comments from a number of colleagues. Responsibility for
the content rests with me.
Author
Affiliations
Roger Clarke is Principal of
Xamax
Consultancy Pty Ltd, Canberra. He is also a Visiting Professor in the
E-Commerce
Programme at the
University
of Hong Kong, Visiting Professor in the
Baker
& McKenzie Cyberspace Law & Policy Centre at the
University
of N.S.W., and Visiting Fellow in the
Department
of Computer Science at the
Australian
National University.
Go to
Roger's
Home Page.
Go to
the
contents-page for this segment.
Send
an email to Roger
Created: 15 October 2004
Last Amended: 1 November 2004
 | These community
service pages are a joint offering of the Australian National University (which
provides the infrastructure), and Roger Clarke (who provides the content).
|  |