In the previous chapter, we developed an instant-messaging application that relies on a central coordinator. As it stands, the central coordinator isn't equipped to handle concurrent requests, which could lead to subtle problems when registering and removing users. There are two approaches that can handle these problems.
The first option is to move the user registry into a database. This approach has a cost. Though a database will ensure scalability and eliminate the possibility of concurrency problems, it will also slow down individual client requests. Using a database makes the most sense if you intend to scale the system to an extremely large audience (with hundreds of simultaneous users). The database approach is demonstrated with the discovery service in Chapter 7.
The second option is to revise the central coordinator and add the .NET threading code needed to safely handle access to the user collection. This approach is ideal when creating a peer-to-peer system for a smaller community (for example, inside the private network of a single organization). This is the approach we'll develop in this chapter.
This chapter also introduces a few additional enhancements to the Talk.NET system. These include the following:
Mechanisms to handle users who supply duplicate user names and users who disconnect from the system without properly logging out.
Client-side threading code to properly handle user-interface refreshes, particularly when multiple messages are received at once.
A modified TalkService component recast as a Windows service, so it can load automatically and run in the background without user intervention.