The Virtualization of Networks

By way of introduction, consider the familiar scenario depicted in Figure 16.1. It depicts a run-of-the-mill campus network or corporate intranet. The network itself is made up of different sorts of nodes: servers, desktop PCs, notebook computers, personal digital assistants, and cellular phones. The lines interconnecting the nodes outline the network's topology. Communication on this network takes place by sending messages from one node to another, typically along client-server communication channels.

Figure 16.1. Computing on the edge. A traditional client-server environment is juxtaposed with devices directly communicating along the network's edges.

Each node on this network assumes a unique identity, denoted by an IP address. Some nodes have statically assigned IP addresses, while others might dynamically obtain one each time they connect to the network. A node's IP address determines message routing to that node: When a message is destined to a node, the sender must first obtain the target's IP address and attach that address to every message packet it sends. This is how communication takes place on much of the Internet or on an organization's intranet.

As networks grow in size, and users demand anywhere/anytime access to networked resources, the assumptions underpinning that mode of operation become increasingly harder to ensure. As an example, consider what happens when a user of the cell phone depicted in Figure 16.1 sends a message to the user of the PDA. Both the cell phone and the PDA use dynamically assigned IP addresses. Thus, they might receive different network identities each time they connect to the network. Yet, the cell phone user might want to send messages to the PDA even after the PDA detaches and then re-attaches to the network; that is, even after it obtains a new IP address. As well, servers behind firewalls and NAT points hide their identities from entities outside the firewall. In such dynamic network environments, the assumption that an IP address uniquely identifies a network entity starts to fall apart.

One solution to these problems centers around constructing a virtual network independent of physical topology. To illustrate this concept, consider a city map. On this map, imagine a point that indicates a company's offices; let's call it JXTA Systems, Inc. When you decide to meet a customer at that office, you might arrange the meeting by referring to the meeting place as "the JXTA Systems offices." This follows the assumption that your meeting partner knows where that office is, and is able to resolve its human-friendly name to a street address (such as 85th Floor, 350 Fifth Avenue, New York). Resolving the address might mean looking it up in a personal address book, on a business card, or, if your office is well-known, by asking a cab driver to simply take him there.

Networking terminology similarly considers an entity's physical address (IP address or Ethernet MAC address) and its human-friendly name (such as server.juxtacorp.com).

In a traditional TCP/IP networking environment, domain name servers (DNS) are used to resolve a human-friendly name to a machine name.

P2P systems strive along a network's edges. As a result, they cannot make the same assumptions about network infrastructure as traditional, client-server style systems can. In particular, they cannot assume the presence of a centralized naming and directory service.

Network identities are also typically shorter in P2P systems than in the traditional client-server world, because devices might frequently disconnect, causing them to obtain new IP addresses with each reconnection. A peer's networked identity might change too frequently for a centralized naming service to catch up. This is similar to JXTA Systems, Inc., moving to a new office every month. It would be very hard, if not impossible, for its customers and clients (and even its employees) to track the office's current location. In essence, you would need a dynamic address book that updates the office's current location just in time as you are about to go there. In other words, your address book would have the capability to find out the mapping of the office's name to its address on demand, instead of storing away that information.

On a network, the capability to delay binding a virtual identifier to an IP address as late as possible in the communication process is referred to as late binding. Late binding is a crucial requirement for both mobile and peer-to-peer systems. JXTA's most remarkable capability is to facilitate the late binding of network resources.

JXTA offers late binding for peer-to-peer networks in two ways:

• By assigning identifiers to a networked resource, and

• By providing a resolver capability to map between virtual and physical network identities at the time access to a resource is requested.

In other words, a network node is identified independently of its IP address, and a mechanism exists to bind a node's (virtual) JXTA identifier to its current IP address whenever a message aims for that node. JXTA's resolver mechanism is independent of centralized naming and directory services such as DNS. A JXTA network based on virtual identifiers is illustrated in Figure 16.2. As you see from the figure, the virtual and IP-based network identities can change independently: The red dots represent "virtual" network identifiers, and the IP addresses assigned to the nodes identify those nodes on the TCP/IP network. The two types of identities can change independently.

Figure 16.2. Virtual and IP-based network topologies superimposed. Virtual and IP-based identities can change independently of one another.

JXTA IDs, Credentials, and Advertisements

JXTA tags identifiers not only to nodes or peers, but also to any networked resource of importance on the peer-to-peer network. That includes chunks of data, pieces of code, groups of peers, or virtual communication channels between peers. Services pieces of software functionality accessible by peers also have their identifiers. JXTA IDs are expressed as text URNs (universal resource names).

A resource's identity on the JXTA network is also determined by that resource's credentials. A credential is a piece of information verifying a resource's identity in human terms. Although IDs are given to resources by the JXTA system, humans assign a resource's credentials. Thus, a peer might have a credential identifying it as belonging to a company. Before trusting that peer, others would request and verify its credential. Credentials don't play a role in building a virtual network; instead, they play a role in making that network trustworthy: Without them, confidence would not be possible in an ever-changing network environment.

What JXTA IDs identify, JXTA advertisements describe. A JXTA advertisement is a structured XML document, which typically includes a resource's unique JXTA identifier, in addition to other pieces of information that describe the resource, such as its credentials. An advertisement might also have an expiration date an absolute time value beyond which the advertisement loses its validity on the JXTA network.

The JXTA network locates resources through advertisements. A peer that decides to advertise itself creates an advertisement, and announces that advertisement on the JXTA network. JXTA's discovery capability facilitates the searching of the network for advertisements that describe a desired resource (for example, another peer's ID). Queries for resources propagate through the JXTA network until a query matches a suitable advertisement. Indeed, much of JXTA's infrastructure facilitates the propagation of advertisements and queries on the network.

When a peer sends out a query message, that query message automatically reaches all peers that are within the sender's multicast radius. (Multicast radius typically implies that the peers reside on the same network subnet; that is, a router is not needed to communicate between them.) Because a query might not match a desired advertisement within the narrow confines of a subnet, JXTA provides a mechanism to propagate queries to a larger network.

Relays

Intuitively, you can imagine JXTA's query mechanism as though you want to find an answer to a question by asking that question from everyone you know. For instance, you might want to find out who played the role of Gelsomina in Fellini's movie La Strada. You would start out by asking that question of everyone in your office and your immediate family. If no one knew the answer, some of your colleagues and relatives would relay that question, along with your phone number or email address, to their friends, who in turn could ask their friends, and so forth. Those with the answer would reply to you, hopefully with the right response (Giulietta Masina).

Message relay offers several advantages. The obvious advantage is that it enlarges the set of peers that can answer a query. In JXTA terminology, relay peers that facilitate query transmission beyond a peer's multicast radius are rendezvous peers. Rendezvous peers are special in that they know about other rendezvous peers, forming a rendezvous network. A peer registers with a rendezvous peer in order to benefit from the rendezvous network's query propagation (see Figure 16.3).

Figure 16.3. Query propagation on the JXTA rendezvous network. Rendezvous peers pass a query message to other rendezvous peers. As matching advertisements are found, they are returned to the query's originator, and are also cached by peers along the query's route.

It might also be that you or your friends know of someone particularly knowledgeable about Italian movies. Thus you'd like to send the query to that particular friend, but you only know her name, not how to deliver a message to her. In that case, you would employ a router, a peer that has the capability to construct and maintain routes to other peers. A route consists of a series of hops that terminate with the desired destination. In JXTA, each hop in a route is denoted by that peer's virtual identifier (see Figure 16.4). Thus routes in JXTA are not related to routes constructed by IP routers on the Internet.

Figure 16.4. JXTA routers are peers with the capability to construct routes to a peer. A route is a list of hops a message has traveled through to reach a destination.

Finally, imagine that your knowledgeable friend speaks only Italian, a language you don't understand. In that case, you could ask a mutual friend who speaks your native language as well as Italian to act as a gateway between you and your Italian friend. On the JXTA network, gateway peers facilitate message relay in environments with heterogeneous network protocols. For instance, a peer might support the HTTP protocol, but another peer might only offer TCP. Sending a message in this network requires a third party capable of acting as a gateway between the two network partitions. Gateways are also useful when communicating with peers partitioned off by firewalls or NAT proxies (see Figure 16.5).

Figure 16.5. Gateways help messages bridge network partitions.

Any peer may assume relay responsibilities, and the more peers do so, the more reliable and robust the JXTA network becomes. A relay peer might be implemented such that it caches advertisements and saves them in persistent store. For instance, a rendezvous peer might cache answers to a query. The next time it receives that query, it uses the answer it already has instead of propagating the query further down the rendezvous network. Similarly, a router might already have route information to a peer; it then no longer needs to forward route requests to other routers. Finally, a gateway might also offer a message caching mechanism, allowing a peer across a network partition to pick up messages intended for it from peers on the outside.

Indeed, one assumption JXTA makes of a network is that there are relays with advertisements matching a query. Without them, query and message propagation would continue ad infinitum. In smaller networks, JXTA operates well with only a handful of peers offering relay capabilities. The JXTA reference implementation in Java provides a configuration option to indicate whether a peer wants to act as a relay, and the kinds of relay functionality it wants to offer.

Endpoints

When you ask for a person's business card, that card typically lists several methods of contacting that person: by telephone, postal mail, email, fax, pager, or mobile phone. In a JXTA network, a peer might similarly be reachable via a number of virtual addresses, or endpoints. An endpoint's advertisement informs other peers about the particular protocol that that endpoint understands (such as HTTP or TCP), and a peer's advertisement might include the endpoints through which to reach that peer (see Figure 16.6).

Figure 16.6. Endpoints abstract out access to a peer. A peer can have several endpoints, each possibly using a different communication protocol.

By abstracting out a peer into a set of endpoints, the JXTA network gains resiliency in the face of changes occurring in a peer's state. For instance, a given endpoint might not always be available on a peer, or a peer might decide to communicate only via certain protocols, depending on the environment a peer operates in (for instance, to conserve bandwidth or to conform to security requirements).

The Significance of Pipes

In JXTA, a communication channel between peers can assume a (virtual) identity. That channel's endpoints are identified, not by the peers' IP addresses, but by their endpoints. Thus, the peers can refer to that channel independently of IP addresses. Should any of the peers' IP address change, the JXTA network simply adjusts message routing to reflect that change the communication via the channel is not interrupted. Because endpoints abstract out access to a peer, the two endpoints of a channel might understand different communication protocols.

In JXTA terminology, virtual communication channels are pipes. Although two peers can exchange messages via JXTA's simple message and query propagation mechanisms, pipes are the main abstraction for direct peer-to-peer communication. Each pipe receives its own JXTA identifier, and the system resolves a pipe's endpoints to physical IP addresses following the principle of late binding. In the subsequent programming example, you will learn how to create pipes and send messages through them.

JXTA pipes assume that only one-way message exchange is possible between two peers. Bidirectional communication between two peers is possible by constructing two pipes, one going each way.

A pipe is not restricted to placement between two peers. Propagate pipes allow the transfer of a message from a node to multiple destinations. How such a delivery takes place is not specified by JXTA. When all peers share a network partition and are within the multicast radius of the sender, IP multicast may be used; otherwise propagate pipes can take advantage of JXTA's relay capability described earlier.

Because JXTA must account for the peculiar conditions on a network's edge, pipes are not assumed to be reliable. Reliable pipes can be constructed by adding a layer of software to the communication channel, ensuring message integrity. In addition to reliable pipes, a JXTA pipe can also be secure, encrypting messages as they travel through it. Figure 16.7 illustrates different types of JXTA pipes.

Figure 16.7. JXTA pipes: (a) The unicast pipe is JXTA's main abstraction mechanism for peer-to-peer communication. It accounts for the asymmetric nature of communication along a network's edge. (b) Secure unicast pipes add message encryption to the basic pipe variety. (c) Propagate pipes facilitate one-to-many communication. (d) Roundtrip communication between two peers is possible by constructing two unicast pipes.