The Messaging Enhancements

The messaging enhancements are the most compelling part of the Intel Peer-to-Peer Accelerator Kit. They include the following:

• Store-and-forward. If this is enabled and you attempt to send a one-way message to a peer that appears to be offline, the message will be cached locally and delivery will be attempted later.

• Tunnel and relay. This feature allows two peers to communicate over a firewall by sending messages through a relay service.

• SSL. As you saw in Chapter 11, it's not possible to use SSL certificate authentication and encryption directly from a peer-to-peer application. Intel's Peer-to-Peer Accelerator Kit solves this problem (with the use of some intensive C++ plumbing).

The messaging enhancements are designed so that they can be easily enhanced in the future. For example, Intel documentation references different methods of firewall traversal such as UPnP NAT and the SOCKS Protocol, which would allow for more flexible handling of peer connectivity. Unfortunately, these solutions aren't implemented in the current (version 1.0) release.

The Intel Peer-to-Peer Daemon

The core piece of technology in the Intel Peer-to-Peer Accelerator Kit is a special Windows service that runs on every peer and handles all communication between computers. This service (shown in Figure 13-1) loads at startup and runs transparently in the background. It acts as a container for all the peer-to-peer services.

Figure 13-1: The Intel Peer-to-Peer daemon service

The peer service performs the following tasks:

• It listens for incoming messages and then delivers them to the appropriate application object (in conjunction with the .NET Remoting infrastructure). This is its most important responsibility.

• It coordinates peer discovery. It automatically submits peer information to the configured discovery service so that a particular application doesn't need to call a Register() or Login() method.

• When delivering messages, it looks up peer location information from the discovery service as required. It also maintains a local cache of peer location information (much as in the Chapter 10 example).

• It encrypts and decrypts messages in secure sessions.

• It stores messages for later delivery if store-and-forward is enabled.

• It sets up a connection with a configured relay server and uses it to avoid firewall or NAT problems. In addition, if configured as a relay server, it routes messages between peers that cannot communicate directly.

• It tracks the list of published files (much as in the Chapter 9 example).

Figure 13-2 shows the how the architecture works in a typical application scenario.

Figure 13-2: Sending a message from one peer to another

Peer-to-Peer URLs and Remoting

The peer service works by mapping peer URLs to Remoting endpoints. In other words, your application works in terms of abstract peer-to-peer endpoints. These endpoints include information about the remote computer and the remote object and indicate additional information such as whether or not the message should be encrypted before it's sent. The peer-to-peer service translates the peer-to-peer endpoint into that actual Remoting endpoint, and it handles the additional steps that may be required to bypass a firewall or create a secure session, and so on.

So far, you've become well-acquainted with the URL format used by .NET Remoting. It starts with the prefix tcp or http (depending on the protocol used for communication) and indicates the remote application and object. Here's an example:

tcp://localhost:8000/RemoteObject

URLs with the Intel Peer-to-Peer Accelerator look quite a bit different. They start with the prefix peer, which indicates that the message must be handled by the Intel messaging enhancements. The peer URL format is shown here:

peer://[PeerName]/[Application]/[Object]?[Parameters]

The peer name is a dynamic GUID that's generated at install time and uniquely identifies the computer (regardless of the application). The application and object have the same meaning as they do in an ordinary Remoting scenario. Finally, the URL also allows a query string portion that specifies additional parameters. There are currently three parameters you can use:

• PeerSecure=True specifies that the communication must be encrypted in an SSL session.

• If you've enabled store-and-forward, PeerExpire=<Time> and PeerLive=<Seconds> can set how long a message is retained if the peer is offline.

When using these options, you won't need to modify the URL manually. Instead, you can use the methods provided by the Intel Peer-to-Peer Accelerator Kit classes.

Remember, the underlying transport mechanism is still an HTTP transfer over Remoting. The peer prefix indicates a virtual transportation specification. The peer service translates peer URLs into the actual endpoints, as shown in Figure 13-3.

Figure 13-3: How the Intel Peer-to-Peer Accelerator Kit maps peer URLs

The Discovery Service

The discovery service is implemented as a web service that exposes three methods: SetPeer() for adding peer information or updating it, RemovePeer() for removing peer registration, and lookup() for retrieving peer URLs. The peer service handles interaction with the discovery service transparently and caches recently looked-up information to optimize performance.

Every directory service contains information about the peer, its URL, and a timestamp. This data is stored and transmitted as an XML fragment.

<PeerInformation>
    <PeerName>pCDA296F7E06511D1BFD300C04FB12345.peer</PeerName>
    <URL>http://10.1.1.26:4375</URL>
    <URL secure="true">https://10.1.1.26:4376</URL>
    <EntryTime>2001-09-28 18:12:19Z</EntryTime>

</PeerInformation>

The timestamp is used to determine which entry to use if multiple registrations are found. When retrieving the peer-connectivity information, the peer service can choose to submit a minimum date, in which case all peer information older than this date will be ignored. The peer service uses this feature intrinsically to retrieve updated information if a message delivery attempt fails.

Intel Peer-to-Peer Drawbacks

Despite its promise, the Intel Peer-to-Peer Accelerator Kit isn't without some limitations. For example, when you examine the peer-to-peer messaging application developed later in this chapter, you'll notice that response times are slower than in the original version. Part of this is due to the need to forward all messages through the peer service. Another consideration is the fact that the Intel Peer-to-Peer Accelerator Kit only supports the HTTP Protocol for exchanging data with the relatively verbose SOAP messages, rather than leaner binary messages over TCP. In addition, the revamped application requires some additional considerations that weren't necessary in earlier implementations, and therefore complicate the code.

Another limitation is the reliance on a discovery service. Intel follows the same approach as the examples in this book by using a separate web service to map peer names to connectivity information. However, this means that you need to include a server in your peer-to-peer system as well as a configuration file that tells all peers where to access it. Though an early beta of the Intel Peer-to-Peer Accelerator Kit experimented with broadcasting, it isn't supported in the release version, and hence there's no way to create fully decentralized peer-to-peer applications (although you can configure multiple discovery servers and thereby reduce the burden on a single computer). It's also important to note that the Intel solution for firewall traversal, while useful, is still more rudimentary than that offered by more mature (and far more complex) peer-to-peer applications such as most Gnutella clients. It requires you to provide an available relay and tell the peer where to find it—additional configuration steps that can only complicate life.

Finally, one other potential problem is the way that the Intel Peer-to-Peer Accelerator Kit generates URLs. As you've seen, these don't use fixed endpoints with the machine name or IP address. Instead, they use a GUID. In order for a peer to connect to another, it must know which GUID to use in constructing the URL. Fortunately, the GUID is machine-specific, so you can distribute the GUID for a server endpoint in a client configuration file, much as you would with .NET Remoting. However, this also means that if you want multiple peers to interact (for example, in a chat application), you'll almost certainly need some sort of central component that allows peers to retrieve the URLs of other peers on the system. This component is in addition to the peer-to-peer discovery service, which isn't application-specific. The server component might map user names or e-mail addresses to GUID values, while the discovery service maps these to the required peer-connectivity information.