New ways better vision

ARCHITECTURAL MODELS

2008-07-03T14:25:00.000+01:00

The three architectural models for p2p considered here are

1 - Atomistic
2 - User-centric
3 - Data-centric

The last two are similar in that they usually rely on centralized servers to mediate connectivity based on directories of users or resources and data. Each model is examined to show its main and distinctive characteristics.

1 - ATOMISTIC P2P:

In the atomistic model (AP2P), all nodes are equally server and client. There is no central administration or connection arbiter, although such might be implemented as distributed services within the network. For purists, this model is the original and only “true” p2p architecture.
Each node in the atomistic model is autonomous and fully manages its own resources and connectivity. Figure 1 shows the schematic connectivity model.

FIGURE 1 An atomistic p2p network is constructed from an arbitrary number of nodes.

Each typically maintains contact with several others,

although virtual direct connectivity can be established between any two.

The atomistic model contains a fundamental bootstrap problem: how to join. The prospective member must somehow first determine which other nodes in the network it can establish connections with. Without a central server, no easy way of determining resource or user availability is apparent in advance.
Two traditional answers are seen to this peer-discovery situation:
· Use a broadcast protocol to send a query to join and await a response.
· Attempt to connect to suitable “known” node addresses that will either accept new nodes or provide further node addresses to try.

When the client has physical connectivity to the p2p network infrastructure, for example in a LAN, it’s feasible to use the broadcast method, effectively calling into the dark, “Hello, I’m here. Who’s available out there?” The implemented protocol determines how this message is framed to be detected by other client nodes and how these nodes should respond. The query can be a request to join a designated group. Multiplayer games often use this method to establish gaming sessions over a local network. Ad hoc sessions are created when several clients detect each other on the basis of broadcast messages plus a matching selection of game, scenario, and other criteria. In these cases, one system becomes the host server for the session.
While broadcast methods can sometimes be used on a larger, general network such as the Internet, the likelihood of successfully reaching active p2p nodes is then much smaller. More practical is to probe known addresses or address blocks for responding clients. The new client can attempt to connect directly to known addresses and through one such node create a response list of other nodes. Alternatively, it can first connect to a published “service provider” node that maintains dynamic lists of active nodes within their horizon. The client downloads this list and proceeds to work through it, attempting to establish a predetermined number of connections.
Note 3: Up-to-date novelists are a valuable resource in AP2P. Considerable effort can be invested in atomistic networks to compile and distribute suitable and updated “seed” lists for new nodes, even using external channels.
Once a successful connection is established to at least one node, a client (or other software) can listen to messages passing through the network and build its own list of active nodes for later connection attempts. Furthermore, if the client is configured to accept incoming connections, the user might find that much of the subsequent connectivity is maintained by “incoming” requests from other nodes.
While the formal lack of central administration in AP2P can cause a significant and frustrating threshold to joining the network, it also means that the network is essentially self-maintaining and resilient within the bounds of its capacity. AP2P is therefore the preferred architecture for systems that wish to ensure maximum availability and persistence of distributed data, despite the acknowledged vulnerability in the common practice of distributing novelists externally.
One or more trusted nodes (or Web sites, or IRC channels) with guaranteed access might in some networks be effectively declared a service provider, mainly to alleviate peer discovery. A fixed address, perhaps of last resort, is then often part of the client distribution and available at first start-up. The fundamental all-nodes-are-equal paradigm is essentially unchanged, except with regard to node discovery.
Lately, some Internet p2p networks are for various reasons moving towards an extension of the service provider concept: a formal two-tier variation of the atomistic model. Particular nodes are then elevated to “super-peer” status because of their proven capacity, connectivity, and reliability. This process is made easier by automatic history and reputation tracking. Reliable or trusted super-nodes can act as list repositories, primary connection nodes, and sometimes search hubs. They provide a sort of backbone network in much the same way that backbone servers came to do for the Internet in general. Later implementation chapters detail some of the discovery strategies in relation to the specific design goals and security concerns in each case.

FIGURE 2 Simple illustration of either user-centric or data-centric p2p.

Even though clients usually connect using the traditional infrastructure, the user sees a different,

peer-oriented namespace with new services unavailable in the underlying physical network.

2 - USER-CENTRIC P2P

The user-centric p2p (UCP2P) model adds to the basic atomistic one a form of central server mediation. In its simplest form, the server component adds a directory based on (usually permanent) unique user identity to simplify how nodes can find each other. Identities tied to client or other entities are also possible, if sometimes less intuitive. Strictly speaking, one should probably refer to “directory-centric” for proper scope, but the term “user-centric” is the one most commonly used. The directory provides persistent logical links that uniquely (and possibly within a specific context) identify each node, and a translation mechanism to enable direct connection by the user over the underlying network infrastructure. In an Internet context, this translates to the current IP numbers corresponding to the registered and available active nodes. Figure 3 shows a simple geometry of this model. In reality, the ongoing direct connections between individual clients would be a much richer web-like structure than this figure suggests.
Clients register with the directory service to announce their availability to the network. Some form of periodic update to this status is tracked so that the server knows when a node is no longer available—either “pings” sent from the client at regular intervals, which is sometimes referred to as its “heartbeat”, or responses to service queries. Users might select a specific transponder status such as “busy” or “extended away” that will be reported to the server, thereby distinguishing between simple node availability[40] and a more nuanced user-selected availability .
A user can scan/search the directory for other users who meet particular criteria, and from the listing they can determine the current connection address. With a known address, the user can then establish a direct client-to-client connection. The target node registered itself as active and known to be online, so it usually responds right away. Depending on the scope of the server mediation, the connection with the directory server might remain, either to exchange supplementary information or to track current p2p transfer status.
User-centric p2p has proven to be the most popular architecture. The most publicized implementation is surely Napster file sharing. This popularity is despite the fact that the UCP2P model has a far greater deployment in the older instant messaging technologies: Miribilis ICQ (“I seek you”, now owned by AOL), AOL Instant Messaging (AIM), and MSN Messenger, to name the best known. Napster as a public representative of UCP2P is doubly ironic, because the primary interest of the users in the system is not to find users, but to find particular content on some remote computer. One would therefore have expected an explicitly data-centric focus, where the MP3-tracks constitute the permanent index of content—after all, to all practical intents, users are mutually anonymous in the system, often away, and their identities (which are arbitrarily user-chosen at sign-up) need not be tracked at all. On the other hand, UCP2P makes the current transition attempts from a free service to a registered subscriber service much easier from the technical point of view.
One issue of concern with UCP2P networks is this reliance on central directories, which introduces specific vulnerabilities and raises privacy issues. A user directory can track user behavior and generate personal profiles. Such profiles can be worth considerable sums of money to the compiler if sold to advertisers. They also invoke the specter of user monitoring by various overt or covert agencies.
If we take the example of instant messaging, these solutions also illustrate another downside of centralized server solutions: closed, proprietary standards deliberately kept incompatible by the companies that control them. Independent services like Jabber attempt to work around the barriers by providing modular support for the different standards and so allow users access from a single client. It remains to be seen whether this strategy will become more than just experimental. Ownership and control of directory services is perceived as increasingly important in the business community the larger the aggregate UCP2P user base grows.
This conjecture is proven by how Napster clones were bought up by commercial interests even as they were being closed down for alleged music piracy.

3 - DATA-CENTRIC P2P

Data-centric p2p (DCP2P) is very similar to the user-centric model, and it can thus be illustrated by the same figure used earlier (Figure 2.3). The distinction made in DCP2P is that the central server maintains an index over available resources, not individual users. The index is a collection of logical links that map the resources to registered nodes in the same way that UCP2P maps identified users.
Again, the term should really be “index-centric” or “resource-centric”, but prevailing usage prefers “data-centric”. However, just as a UCP2P directory can indirectly access content (think Napster), it’s possible to indirectly access individuals from a properly structured DCP2P resource index. In this respect at least, UCP2P and DCP2P can be seen as interchangeable and the choice somewhat arbitrary.
When clients register with the DCP2P server, they mainly provide a list of currently available resources on that node. Although this is usually assumed to be data content of one kind or another—that is, files or documents—nothing requires it must be. Resources can include more abstract entities, such as client-managed services, storage, gateway interfaces, and other intangibles. Users can in DCP2P architecture search for and access data (or content) held on other nodes. With data in primary focus, it’s understandable that different forms of content management solutions turn mainly to DCP2P. It is the area of greatest excitement and promise for p2p in business, as opposed to private use. Access in DCP2P tends to be more governed by rules than in UCP2P, especially in corporate contexts. Not everyone is allowed to access everything, at any time. Exclusion/admittance policy requires more “intelligence” in server index and client management, so this kind of architecture is still very much under development, targeting enterprise solutions. Furthermore, security issues are paramount because of the deep access into registered nodes—both in terms of data and functionality, and the often sensitive nature of the content.

4 - LEVERAGED P2P

When dealing with the last two entries, computation-centric and next generation Web models, I would like to use the term “leveraged p2p” (LP2P), insofar as such implementations are to be considered in purely peer-to-peer contexts. Each can be combined with the other, and also with elements from the previous three p2p architectures. They might also be fully incorporated into these respective p2p contexts to achieve synergies that can dramatically improve network performance. However, it didn’t feel appropriate to include deeper discussions of these models in this book.

FIGURE 3 Simple illustration of traditional distributed processing.

Typically little or no communication occurs between nodes.

Data is owned by the central server(s), and tasks are sent out to nodes that sent back results.

Take for example distributed processing. Traditional DP implementations tend to be highly server-centric, as shown in Figure 2.4, because the primary interest has been for a single owner of large amounts of raw data to process it using distributed and otherwise idle resources. Owners of idle capacity, say a PC on a network, install client software and register with the server. They then let the client autonomously request and process data for the server owner, but generally have no insight or control of the process, or the data. The best known example is the SETI @home Project, which tries to analyze the vast reams of data available from radio telescopes in order to detect evidence of intelligent life in the universe.
The thorny issue of data ownership and potential rights to processed results in a public DP setting arose with a comparable distributed effort to identify genes in human DNA. Ostentatiously hosted by a university for cancer research, any results gleaned turned out to be patentable and exclusively owned by a private company. When this fact was made public, many users left that DP network in disgust.
Using DP in a proper p2p context is comparatively rare as yet. In fact, the usual definition of “large processing tasks segmented into component blocks, delivered to a number of machines where these blocks are processed, and reassembled by a central machine” is pretty clear about the strict hierarchy model.
One potential network-specific application of DP based on p2p is distributed indexing, where nodes in a DCP2P network assume responsibility for a portion of the total indexing task and work together in fulfilling search requests. Various distributed search schemes are possible, index-based or instance-compiled on varying scope.
A combination of DP and the new Web, sometimes called “Web Mk2”, offers other prospects. In the p2p context, one can envision autonomous, roaming Web agents opportunistically using p2p nodes as temporary hosts as they go about their assigned information-gathering tasks—a kind of benign Internet “worm”.

Peer to Peer Properties and Components

2008-07-03T14:18:00.000+01:00

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.

Network Topologies

2008-07-03T13:54:00.000+01:00

Several network topologies can be used for connecting P2P systems. In this section, we discuss the major P2P network topologies in order to explain how information can be transmitted between peers effectively.

The Hierarchical Topology:

One of the most common topologies is the hierarchy. Every time you type a website URL into your browser , you are using a system called DNS, or Domain
Name Server. This system is set up in a hierarchy, with root servers at the very top levels. The hierarchy topology looks like Figure 1.1. For several years now, critics have called for an overhaul of the DNS architecture because the root servers represent a single point of failure. However, because the entire system is based on replication and the chance of the DNS system going down is very small, no real work has occurred in this area.

The Ring Topology:

Token Ring is a network topology that uses the concept of passing a single token around to the computers connected in a ring pattern. When a machine receives the token, it can send information out onto the network. The ring topology isn’t used much anymore for common networks, but does provide an interesting pattern for load-balancing a single-server system or hierarchy. The top rung of a hierarchy topology could actually be a ring of servers that balance the network requests. Figure 1.2 shows what a ring topology looks like.

The Client-Server (Centralized) Topology:

By far the most common topology is the client-server, or centralized, topology. The terminology of client-server has been with us for many years; more recently, the term centralized has been used to describe a system in which a single computer, the server, makes services available over the network. Client machines contact the server when the services are needed. Obviously, the more clients in the system, the larger the server must be. At some point, the server will need to be replicated in order to handle the traffic volume from all clients. Figure 1.3 shows an example of the centralized topology.

The Decentralized Topology:

The decentralized topology is a network topology that comes closest to being truly peer-to-peer. There is no central authority, only individual computers that are able to connect and communicate with any of the other computers on the network. When a packet of information starts its travels on the Internet, it is basically traveling through a decentralized topology. Information within the packet itself tells each computer where to send the packet next. Figure 1.4 shows an example of a decentralized network topology. Basically, all of the peers in the system act as both clients and servers, handling query requests and downloads while also making media searches and download request themselves.

The Hybrid Topology:

In the hybrid topology , we have an example of a situation where the individual computers are considered clients when they need information. The client that needs information will contact a central server (the centralized servers are distributed in the example shown in Figure1.5) to obtain the “name” of another client where the requested information is stored. The requesting client will then contact the client with the information directly. With the hybrid, a computer can be either a client or a server. This is the topology used for the Napster [8] [16] system—individual peers contact a localized server for searching and proceed to contact peers directly for media downloading.