This would be simple enough, but…
Why would you need to have a server console at all? Also, by the nature of a service, it's perfectly fine to have it executing "forever".
After all, this is not a "real" service anyway. The "real" service could be the one which is made as a Windows Service. Then it will execute hosted by the service controller which will also be able to stop the service; and you will only need to handle the service stop event, in case you need to perform some post-mortal action. In this approach, your service will keep executing when the users log on and off, and will start before anyone logs on. On Windows, that is a civilized way to proceed.
So, first thing you need to think about is the sense of such console use and closing. Maybe, temporary, research or experimental character of your work will not justify this complication.
However, if you still want to develop some home-baked approach to "server stop", you should remember, that in your application, you are supposed to use not just TCP (or any transport) it its pure form and some ad-hoc use, but you are supposed to create some
application-level protocol:
http://en.wikipedia.org/wiki/Application_layer[
^].
In fact, you always have such protocol de-facto, even if you don't just call it a protocol.
When you remember that, you will see that you can have some "application" messages, as well as "control" messages; and one of them will be the "stop the service" message. Another approach could be counting all the clients on server side. At first, the number of the client is 0, then it grows, but as soon as it becomes 0 again, the server terminates.
However, to do things properly, you should always use threading. On the server side, you need at least two threads: one listening and accepting the newly connected clients, and another one is implementing the application-level protocol by reading/writing from/to the network streams or sockets. (And I strongly advise to use async APIs; threads are way more straightforward, more importantly, thread synchronization is not application-specific, so you use the same approach without a need to review it per application.)
You can find further ideas in my past answer:
Multple clients from same port Number[
^].
—SA