JavaScript Editor
JavaScript Debugger
|
|
To learn more about the Intel Peer-to-Peer Accelerator Kit, you can explore the samples (and if you're somewhat more ambitious, the source code for the toolkit itself). Unfortunately, the samples are only provided in C# syntax. However, as you no doubt already know, almost all C# code can be converted to VB .NET code on a line-by-line basis. This means that once you acclimatize yourself to the altered syntax, case sensitivity, and preponderance of curly braces, you should be able to determine exactly how the code samples work.
The next few sections introduce each of the sample applications and briefly describe the underlying operation and design decisions. You can also refer to the readme.htm file that's provided in each sample directory, which supplies limited information about how to test the example.
The Intel Peer-to-Peer Accelerator Kit also provides basic functionality for transferring files and monitoring their progress. The underlying operation of the file copy feature is fairly similar to the custom approach developed in Chapter 4. Files become available when they're "advertised," at which point they're dynamically associated with a unique GUID. If a peer wants to download the file, it uses the GUID in its request. Unlike our custom solution, the use of a peer service allows shared files to persist between application sessions. To remove a file from the available pool, its advertisement must be specifically cancelled. If a physical file is moved or deleted, the advertisement will still remain and an error will occur if another peer tries to download the file.
The FileCopy example is a console application that allows you to transfer a file between two peers. This functionality does not include any way to associate application-specific metadata (such as MP3 song information) with a file, so you still need to add these features to a central coordinator or lookup service if you need them.
This Messenger example is a Windows application that allows instant messaging, similar to the Talk .NET application. It uses a global session concept, whereby all registered peers become a part of the same chat room. Messages are sent to every peer, which means that the system won't scale well to extremely large networks.
The Messenger is similar to the decentralized version of Talk .NET because the central coordinator (called the listener) is used for storing registered user URLs. It doesn't perform the actual message delivery. The central coordinator uses a "push" model. Whenever a new user joins the system, the new user list is sent to each registered peer. When sending a message, the peer goes through each entry in the local copy of the user list and contacts each peer separately.
The peer clients aren't configured with any information about the location of the listener. When launching a peer client, you must supply a command-line parameter that indicates the peer ID for the machine where the server is running. The listener displays this information in a console window when it first starts. (See Figure 13-10.)
| Note |
One significant limitation in the design of the Messenger application is the fact that it doesn't use interfaces. This means that the shared assembly (ListenerObject.dll) must contain the complete code for both the server and peer remotable objects. In fact, this DLL even includes the Windows form code, which means that the server must be updated if you want to change any aspect of the peer UI. |
The Scribble example is a collaborative Windows Forms application that allows multiple peers to share a single whiteboard. Whatever one peer draws on the whiteboard will be replicated to all registered users.
The Scribble example uses the same design as the Messenger. It's composed of two components: a Scribble server application and a Scribble client application. The Scribble server component records a list of registered users and provides the user list to all peers that connect with the system. The peers, however, communicate directly.
| Tip |
The readme.htm file included with the Scribble example shows the logic in detailed pseudocode so that you can understand the operation of the application without needing to dive into the C# source code. |
SharedCyclesP2P (see Figure 13-11) is a Windows application that demonstrates one way to build a distributed task manager. SharedCyclesP2P uses a foreman application, which divides a computer-intensive graphic into a user-defined number of smaller jobs and a large number of worker peers that perform the actual work. The foreman assigns job portions to the pool of workers and combines the results. One of the most interesting aspects of the SharedCyclesP2P application is that it tackles a relatively practical example (rendering a ray trace drawing), rather than the more rudimentary prime number search that's used to demonstrate distributed computing in Chapter 6. Figure 13-11 shows a partially complete rendering job displayed in the foreman.
The readme.htm file included with SharedCyclesP2P includes detailed information for testing the example. The most significant limitation in SharedCyclesP2P is that it doesn't provide a discovery mechanism for locating worker peers. Instead, you need to take the peer ID, which is displayed in the console window, and paste it into a text file. The foreman reads this text file to locate available workers. Clearly, you would need to replace this mechanism with some type of registration mechanism or an application-specific discovery service before making this into a production application.
ShareBaby2 (see Figure 13-12) is a file-sharing Windows application that works somewhat like the example presented in Chapter 9. It makes use of a discovery service and database for sharing file keyword information and uses multiple threads to manage concurrent uploads and downloads. However, it doesn't offer the same features for file-progress monitoring. It doesn't use the simple FileCopy API included with the Intel Peer-to-Peer Accelerator Kit.
The peer ASP host is a console application that shows how you can host an ASP.NET web service inside a peer-to-peer application. In order to perform this feat, the ASP.NET process is actually hosted inside a custom host application instead of the Internet Information Server (IIS). It's a thought-provoking example of how you might want to combine these two technologies, but it does introduce an additional layer of customization that could make it difficult to upgrade your application to future .NET Framework releases and adopt new features.
|
|
Free JavaScript Editor
JavaScript Editor
