We've got a working echo server and it can handle multiple clients simultaneously, so we're pretty close to having a functional chat client. However, our server needs to broadcast the messages it receives to all the connected clients. Sounds simple, but there are two problems that we need to overcome to make this happen.

First, our protocol needs an overhaul. If we think about what needs to happen from a client's point of view, then we can no longer rely on the simple work flow:

client connect > client send > server send > client disconnect.

Clients can now potentially receive messages at any time, and not just when they send a message to the server themselves.

Second, we need to modify our server to send messages to all of the connected clients. As we are using multiple threads to handle our clients, this means that we need to set up communication between the threads. With this, we're dipping our toe into the world of concurrent programming, and it should be approached with care and forethought. While the shared state of threads is useful, it is also deceptive in its simplicity. Having multiple threads of control asynchronously accessing and changing the same resources is a perfect breeding ground for race conditions and subtle deadlock bugs. While a full discussion on concurrent programming is well beyond the scope of this text, we'll cover some simple principles, which can help preserve your sanity.