December 20, 2014
Hot Topics:

P2P Dynamic Networks

  • November 7, 2002
  • By Sams Publishing
  • Send Email »
  • More Articles »

Adaptive Broadcast

As mentioned in Chapter 1, "What Is P2P?," adaptive broadcast tries to minimize network utilization while maximizing connectivity to the network. You can limit the growth of discovery and searching by predefining a resource tolerance level that, if exceeded, will begin to curtail the process. This will ensure that excessive resources are not being consumed because of a malfunctioning element, a misguided peer, or a malicious attack. Adaptive broadcast requires monitoring resources such as peer identity, queue size, port usage, and message frequency.

Rules can be used to complement metadata to build sophisticated discovery techniques (See Table 6.5).

Table 6.5 Ping Map with Peer Identity, Metadata, and Rules

IP Address:Port

Unique ID

Metadata

Rules

172.16.1.3:

ABCD-3456-2345-DEFA

Dial-up, # of concurrent connections

Congestion -> Throttle

Connections -> Accept

172.16.1.4:

DECF-5432-5643-EFDA

DSL, # of concurrent connections

Congestion -> Throttle

Connections -> Accept

12.239.129.4:

DCDD-1324-7654-DEAC

T1, # of concurrent connections

Congestion -> Throttle

Connections -> Accept

...

...

...

...


The ALPINE Network implements a form of adaptive broadcast in its adaptive social discovery protocol. It's based on the ALPINE-defined datagram protocol DTCP. See http://www.cubicmetercrystal.com/alpine/overview.html for more information on ALPINE networks and protocols.

Identity and Presence

As discussed in Chapter 3, "P2P Application Types," users of instant messaging (IM) systems must be uniquely identified. How a user is identified is fundamental to the operation of the system.

Identity has also proven fundamental to discovery and P2P systems in general. Our simple ping map example was unable to satisfy the critical requirements of P2P networks. It had no way to resolve the dynamic and transient nature of peer participation.

Peers and resources need to be uniquely identifiable. This identity must not be limited to current session or current IP address identification. It must persist to enable contextual information and historical interactions to be stored and subsequently restored. In effect, it is required to accumulate the knowledge necessary to support sophisticated P2P networks. Presence information tied to identity can be used to ensure that peer maps are consistent and represent the current state of the network. Knowing when a peer is online is required for building efficient, distributed, and user-centric systems.

Virtual Spaces

Broadcast messages require senders and receivers to agree on the semantics of the exchange (protocol) to create groups of collaborating nodes. The formation of a group of nodes creates a virtual space that shares a common context. Even at the base level of discovery, there is a significant amount of cooperation and collaboration involved. This is before any real work, such as transferring files, messages, transactions, and so on has even been initiated. A virtual space implies more than simple connectivity.

Another way of looking at virtual spaces involves JXTA. Before JXTA, a Java developer's choices for P2P technology were limited. If you were developing a file sharing application, the likely choice would have been the Gnutella protocol; for instant messaging, it would have been ICQ. The protocols' incompabilities divided the network into groups of applications based on protocols. With JXTA, the protocols are mixed-and-matched freely.

A natural result of JXTA mixing-and-matching protocols in P2P applications is found in peer groups. Peer groups are formed by combining groups of peers to serve a common interest or goal defined by the application the peers were built to solve. Peer groups provide services that are not available to other peers in the P2P network.

The J2SE implementation of JXTA organizes peer groups hierarchically. At the root is the NetPeerGroup, of which all peers are members by default (see Figure 6.4). On a local network, the NetPeerGroup provides peers with global connectivity according to the restrictions imposed by network administrators.


Figure 6.4

JXTA provides a view of a virtual space as a collection of common services shared by a group of peers.

The common services shared by the members of the NetPeerGroup include the following:

  • Discovery service

  • Membership service

  • Resolver service

  • Endpoint service

  • Pipe service

  • Peer Info service

Peers self-organize into peer groups, each identified by a unique peer group ID. So, it is the peer group ID that uniquely identifies the virtual space in the JXTA protocol.

Discovery, identity, and namespaces are the building blocks of a virtual space. Discovery determines the horizon or scope of membership. Identity uniquely defines the membership, and namespaces supply the context for membership.

In the computing disciplines, the term namespace conventionally refers to a set of names; that is, a collection containing no duplicates. In the context of P2P, a virtual namespace augments current addressing technology. It provides the context to support consistent identification and service composition.

You can define context as any information that can be used to characterize the situation of an entity or an action. Formal context definition is critical to enabling richer integration between distributed systems. Our software must be more intelligent and adaptive to the environment. For software to be adaptive, it must be able to "reason" and make assertions based on situational analysis. A virtual space provides the context. Members share a common protocol and metadata definition. P2P will help provide identity, presence, and context within the virtual spaces of cyberspace.

Discovery Implementations

This section discusses some P2P implementations of discovery.

Gnutella Discovery

Gnutella uses a broadcast-messaging protocol for peer discovery. The Gnutella net has no hierarchy. Every peer is both a client and a server (servent). Each Gnutella peer knows about the peers to which it is directly connected. All other peers are invisible, unless they announce themselves by answering to a broadcast request or a query.

After making the initial connection to a peer, you must handshake. Currently, the handshake is very simple. The connecting peer sends

GNUTELLA CONNECT/0.4\n\n

The accepting peer responds with

GNUTELLA OK\n\n

A Gnutella network is cyclic, in that loopback messages are possible. All messages have a unique ID (GUID). Gnutella peers check the message ID and if they have received the message before, they discard the request. If they have not seen the message, they route it to the peers to which they are directly connected.

JXTA Discovery

Per the specification, "JXTA does not mandate exactly how discovery is done. It can be completely decentralized, completely centralized, or a hybrid of the two." JXTA enables discovery by providing a discovery service, which provides a mechanism in JXTA for discovering advertisements. The Peer Discovery Protocol (PDP) defines a protocol for requesting advertisements from other peers, and responding to other peers' requests for advertisements.

Technically, advertising means sending an advertisement to everyone on the network. An advertisement is an identifier for any network resource that a using entity might need. A JXTA advertisement is platform-independent, and is typically represented by an XML document.

In JXTA, you can control the scope of discovery by specifying a threshold. The threshold is an upper limit of the number of advertisements that the requesting peer specifies. The responding peers cannot exceed this limit. Each PeerGroup has an instance of a DiscoveryService, so the scope of the discovery is limited to the group.

JXTA discovery mechanisms include local broadcast, peer invitation, message cascading, and discovery using rendezvous peers.

Rendezvous peers help an isolated peer by quickly seeding it with network information. Rendezvous peers provide peers with two possible ways of locating peers and other advertisements:

  • Propagation—A rendezvous peer will pass the discovery request to other peers on the network it knows about, including other rendezvous peers that will also propagate the request to other peers, a process illustrated in Figure 6.5.

  • Cached advertisements—A rendezvous peer can use cached advertisements to reduce network traffic, and can use cached advertisements to respond to a peer's discovery queries.


Figure 6.5

Rendezvous peers provide "fan-out" capabilities by propagating discovery requests from peers initiating discovery.

Relay peers also have a special role in JXTA discovery. These are peers that are capable of forwarding requests to rendezvous peers and other relay peers. They are used to provide connectivity, or a bridge, from behind a firewall or NAT device to the peer network. Any peer can query a peer relay for route information, and any peer in a peer group may become a relay. Peer relays typically cache route information. Route information includes the peer ID of the source, the peer ID of the destination, a TTL for the route, and an ordered sequence of gateway peer IDs (see Figure 6.6).


Figure 6.6

Relay peers can be used to circumvent firewalls and NAT devices. Typically, these IP addresses (relay and rendezvous) will be configured in the PlatformConfig file of the JXTA platform.

When a peer sends its advertisement to another peer, it can expect the other peer to reply by sending its advertisement back. This way, both peers will have the other party's advertisement.

Advertisements are stored in a persistent local cache (the cm directory). When a peer activates, the same cache is referenced. A JXTA peer can use the getLocalAdvertisements method to retrieve advertisements that are in its local cache. If it wants to discover other advertisements, it uses getRemoteAdvertisements to send a DiscoveryQuery message to other peers. DiscoveryQuery messages can be sent to a specific peer, or propagated to the JXTA network.

In the J2SE platform binding, DiscoveryQuery messages not intended for a specific peer are propagated on the local subnet utilizing IP multicast, and they're also propagated to the configured rendezvous peers. A peer includes its own advertisement in the DiscoveryQuery message, performing an announcement or automatic discovery mechanism. Only peers in the same peer group will respond to a DiscoveryRequest message.





Page 3 of 4



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel