It depends on what do you use for connection and communication.
You could use
System.Net.Sockets.Stop,
http://msdn.microsoft.com/en-us/library/system.net.sockets.tcplistener.stop.aspx[
^].
You could also use one of
System.Net.Sockets.Socket Disconnect methods,
http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.aspx[
^].
In general case, it will cause an exception on the client side. In my opinion, this situation lacks the graceful disconnection ceremony, but is perfectly valid. The client side should run the network communication code in a separate thread, should handle all the exceptions on the very top of the stack, and, in the case of network exceptions, be ready to reconnect.
Here is why I think working without graceful disconnection can be fine: the disconnection can happen non-gracefully anyway, by many reasons, such as system shutdown (in emergency of not), physical connection disruption and more. In all cases, the client part should handle all those events properly.
[EDIT]
It looks like you need to display some reason for disconnection on the client side to show that the disconnection was done by the initiative of the server by some logical reason. My idea explained above still works. You can simply add some special "disconnection alert" message to your application-level game protocol (something you always have, please see
http://en.wikipedia.org/wiki/Application_layer[
^]). This special message (could be just one control byte) can be sent to a selected client(s) from the server.
—SA
Submit an article or tip