All of the peer-to-peer applications developed so far in this book have been designed from the ground up, using nothing but built-in .NET technologies. You need to code the business logic, decide how the interaction of distributed nodes will take place, and create the network and directory or lookup services. Now, in the last two chapters, we'll consider some new options.
In this chapter, we'll look at how you can create a peer-to-peer application by using an existing peer-to-peer network. You'll learn how you can create your own application that piggybacks on the popular Windows Messenger network or uses the Groove platform. Both of these choices are best suited for specialized applications over which you don't need complete control. They also present some interesting choices. For example, you might want to build a collaborative tool that you can run with a Groove tool or use the Windows Messenger as a background to send messages that coordinate multiple workers as they process a distributed task such as the one shown in Chapter 6. We'll also briefly consider some other peer-to-peer development platforms.
Windows Messenger is a popular protocol for instant messaging between peers. It uses a centralized peer-to-peer model. All messages are sent through the server using peer-to-server connections, except for file transfer and voice chat.
There are three types of servers involved in the Messenger system:
Dispatch server. This is the initial point of connection. It refers users to the appropriate notification server. The dispatch server can be found at messenger.hotmail.com on port 1863.
Notification server. This is where the sessions are maintained while users are interacting with the system.
Switchboard server. This server acts as a gateway between users for chat. A new switchboard session is opened for every chat window in Messenger. All messages are routed through the switchboard, including file transfer and voice chat invitations.
The actual MSN Messenger protocol is fairly simple. It consists of predefined ASCII messages that are exchanged over a TCP connection. The latest version of this protocol (MSNP7) is described unofficially by Mike Mintz at http://www.hypothetic.org/docs/msn. Using the information provided here, in conjunction with the standard .NET TCP classes, you could connect to a Messenger server, retrieve contacts, send messages, and so on.
Writing this type of application wouldn't be too difficult, but it would involve some detailed study of the Messenger protocol. A much easier option is to use the MSNP Helper API for .NET, an open-source .NET component that allows you to interact with the Windows Messenger network almost effortlessly. You can download the MSNP Helper API and documentation and read any recent news at its SourceForge.net home page, http://msnphelper.sourceforge.net. Documentation is in the form of an HTML Help class library reference, and the component is included in a single assembly named msnp.dll, which you can reference in your projects.
The MSNP Helper API for .NET doesn't use the MSNP7 protocol. Instead, it uses the somewhat older MSNP2 protocol, which is the only protocol to have been released officially. Presumably, the officially undocumented MSNP7 protocol could change without warning. Neither protocol has any official support.
So why would you want to create a custom program that uses the Messenger network? One reason might just be to access or add features that wouldn't otherwise be available, such as the ability to send large messages, encrypt messages before they reach the server, or log the status of users over a long period of time. Or, you might want to create another type of application that isn't primarily concerned with sending and receiving messages. Some possibilities include the following:
A long-running service that monitors when a user appears or leaves and launches other tasks accordingly.
An automated tool that sends certain types of messages to specified users at specified times.
Some type of task processor that routes business-specific commands through Messenger. In this case, you would probably define the commands using string constants (much as in Chapter 9).