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:
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 ImplementationsThis section discusses some P2P implementations of discovery. Gnutella DiscoveryGnutella 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 DiscoveryPer 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:
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. Discovery ProtocolThe information that should be defined in the discovery protocol depends on various factors. If all your problems could be solved with the ping/identity map, the resulting protocol would be simplistic. However, there are many additional considerations, such as routing impediments, network connectivity, security, presence, and so on. As a result, protocols must be more complex than simple ping requests. JXTA defines two protocols specific to discovery:
The organization of information into advertisements simplifies the JXTA protocols required to make P2P work. The format of the advertisements themselves dictates the structure and representation of the protocol data. |
