THE LAST CHAPTER CONDUCTED a whirlwind tour of Remoting, .NET's object-based model for communication between applications and across a network. Remoting is a surprisingly flexible technology. By default, it's tailored for traditional enterprise computing, in which all the work is performed by a central group of powerful server computers. But with a little more effort, you can use Remoting as the basis for a peer-to-peer system that uses brokered communication. In this chapter, we'll explore one such example with an instant-messaging application that relies on a central coordinator. Along the way, you'll learn the advantages and drawbacks involved with using Remoting in a peer-to-peer project.

Though Remoting is fairly easy to use, there can be a fair bit of subtlety involved in using it correctly. In the example presented in this chapter, it's easy to ignore threading and concurrency problems, scalability considerations, and security. These details are explored in more detail in the next chapter. In this chapter, however, we'll concentrate on creating a basic, reliable framework for a messaging application based on Remoting.

Because the code is quite lengthy, it won't be presented in this chapter all at once. Instead, it's broken down and dissected in detail throughout the chapter. But before we consider a single line of code, we need to plan the overall architecture of the system, which we'll call Talk .NET.

Envisioning Talk .NET

Every Internet user is familiar with the basic model for an instant-messaging application. Users log on to some sort of central authority, retrieve a list that indicates who else is currently online, and exchange simple text messages. Some messaging platforms include additional enhancements, such as file-transfer features and group conversations that can include more than two parties.

All current-day instant-messaging applications rely on some sort of central component that stores a list of who is currently online as well as the information needed to contact them. Depending on the way the system is set up, peers may retrieve this information and contact a chosen user directly, or they may route all activity through the central coordinator. This chapter will consider both alternatives. We'll use the central coordinator approach first.