One way you could do this, is to have all client apps broadcast (multicast) their statuses.
Your controlling server listens for these updates and renders them on a screen. If it failes to receive a message in some window, it's assumed to be disconnected.
Why do this?
1. This method is stateless, the server and client don't need their own set of protocols and connections.
2. The server doesn't need to keep track of client connections, it just receives updates via UDP that it decodes and displays.
3. The server won't need a whole bunch of threads to track each client.
How would it work? You start a background thread to manage the network comms. That thread just listens for multicast traffic. When it receives something, it decodes it and uses PostThreadMessage to send it to the main thread that the GUI runs on. The main app can manage the display, track which clients are up, time out old clients ... all that stuff.
Where do you begin? Start with an MFC app that can manage the display, has objects to represent clients and their states and receive updates using locally defined messages.
When that is stable, you can start looking at the comms. Stateless UDP stuff is much easier to handle than TCP. It just receives a packet, decodes it and passes it on to the main app (with one of those locally defined messages) or discards it if it's nonsense (with an entry in the application event log).