Peer to Peer Properties and Components

Looking at conversation properties in general lets us identify some essential p2p (Peer to Peer) properties and components more clearly. Defining these basic terms is important for later discussions.

1 - Identity

This property simply serves to uniquely identify any user, client, service, or resource, and is fundamental to any p2p context. The practical implementation [10] of a network’s identity namespace critically determines or limits the scope of application of the p2p network. Another critical identity issue deals with identifying and tracking individual messages.

2 - Presence

As a property, presence defines the arbitrary coming and going of actors in a dynamic conversation. As a component, it represents the mechanism by which users, applications, services, or resources can manage and communicate information about their current state. Note that “presence” can go beyond the simple state model to convey all manner of context-specific information for a particular conversation.

Note : Presence is a crucial issue in human-usable p2p applications. Qualitatively speaking, human users find a well-supported implementation of simple presence as the single most valuable and useful feature in a p2p client.

3 - Roster

One most often identifies roster as a list of frequently contacted identities. The corresponding component provides short-list entry points into a chosen peer community but is often underestimated in terms of its potential automation utility to the user-see “agency”. In particular, applications and services can make use of a roster to intelligently share resources, filter conversations, and determine appropriate levels of trust automatically, without the user’s constant attention and intervention.

4 - Agency

With relationships to both identity and roster, agency defines the ability for an application to act as an autonomous client. This can mean initiating, managing, coordinating, and filtering conversations that the user would be interested in or has set up rules for e-mail filtering rule sets are but a simple precursor to agency. In some cases, the agent might act with vested formal authority on behalf of the user, probably leveraged with one or another form of digital signature or certificate.

5 - Browsing

As yet comparatively rare in p2p implementations, the ability to browse available peers, services, applications, resources , and relationships is an important but underrated feature that is only marginally supported in the current paradigm of searching the network or central user/resource database. We find its best known implementation in the form of the browser built into Microsoft Network Neighborhood.

6 - Architecture

In this context, architecture mainly denotes how messages are managed and passed between endpoints in a conversation. One dimension for describing this term is to locate the process somewhere on the scale of client-server to atomistic peer. Another is degree of distribution of services and storage. The relevance of any description depends on the p2p context.

7 - Protocol

Current p2p implementations rest on the packet protocol layer of TCP/IP, sometimes UDP/IP , overlaid with more sophisticated application and session protocols to create the virtual network that defines a particular implementation space. Ideally, the implementation should be fairly agnostic about this layering process and be able to transparently translate across different protocols as required.
This list of components is used to provide a baseline table for a summary comparison between the different implementation architectures. Although neither exhaustive nor the only way to examine functionality, these items are a useful way to highlight significant differences between implementations. Maintaining a focus on these primary characteristics helps a user evaluate critical features and discount non-essentials in a given implementation’s feature list.
The relative importance of each characteristic is largely dependent on intended purpose and scope of the application, but some general conclusions are still possible. One is the overall importance of identity. This might seem trivial—surely you need some form of identity to communicate—yet some implementations totally lack any concept of user identity. In such cases, the implementation works because the purpose doesn’t require any defined identity. Others allow arbitrary, even multiple, user selectable names that are unique only within a particular context. Even with a well-defined identity, the question remains as to what exactly that identity is tied to-message, person, role, digital signature, software, computer component-each has advantages in certain contexts, and clear limitations in others, particularly in the degree of addressability, security, or portability each offers.
Another conclusion is that some characteristics, such as presence, are often undervalued in p2p designs. This view applies even to basic online status, let alone to more advanced concepts of presence which might be applicable to a wider context involving autonomous agencies acting on the behalf of a user.