我不明白你为什么要使用 client.Connected 。这个问题对我来说很简单;我到处都遇到这种断线，从来没有遇到任何问题。



这个想法是：你应该有一个主循环，你可以与所有客户交换数据。在这个循环中，一切都应该在try-catch循环下完成。如果您在实验中第一步捕获所有异常和一些客户端断开连接，您将看到抛出的异常并在下一版本的代码中专门处理它们。从异常信息中，您将看到哪些客户端已断开连接（客户端表示为表示远程套接字的 Socket 的实例，或的实例> TcpClient的）。确定后，从客户端集合中删除客户端并继续与其他客户端循环，或执行所需操作。当然，这样的事情应该在客户端完成。



请注意，有一个特殊的断线情况，这是一个问题。如果断开应用程序（刚刚终止它），则会立即检测到该情况并引发异常。问题是当你在物理上断开网络电缆而不是改变任何东西时。仅在相对长的超时后才检测到这种情况。 （您可以定义超时值，但合理的是有相当长的超时时间。明亮的一面是您可以重新连接电缆，然后通信将继续。）基本上，总是涉及这种等待。例如，您可以在LAN上进行试验。解决方法是检查与单独通道的物理连接和短暂的超时值（ping是这样的选项之一），但这种策略是多余的/浪费的，几乎没有多大意义。



我假设你在同一个线程中使用所有客户端（甚至只与一个客户端一起工作）。但是，这里的主要问题是线程。您确实需要在服务器端至少有两个独立的通信线程：一个线程接受新客户端，另一个线程从/向网络流读取/写入。当然，您需要对共享数据使用适当的锁定（例如连接客户端的集合或与客户端相关的其他内容，例如客户端相关数据）。



请参阅我过去的回答：

套接字编程中的业余问题 [ ^ ]，

同一端口号码的多个客户端 [ ^ ]。



注意我关于优雅断开连接的段落：我试着解释为什么它没有意义：应用程序应该是无论如何都准备好了所有的断开连接。

-SA

I don't understand why would you use client.Connected at all. The problem looks very simple to me; I face such disconnections everywhere and never had problems with it.

The idea is: you should have some main cycle where you exchange data with all clients. Inside that cycle, everything should be done under the try-catch loop. If you, for an experiment, at first step, catch all the exception and some client disconnects, you will see what exceptions are thrown and handle them specifically in your next version of the code. From exception information, you will see what client has been disconnected (a client is represented either as the instance of Socket representing remote socket, or an instance of TcpClient). When you determine that, remove the client from the client collection and continue the loop with other clients, or do whatever is needed. Naturally, something like that should be done on the client side.

Note that there is one special case of disconnection, which is an issue. If you disconnect the application (just terminated it), the situation is detected immediately and the exception is thrown. The issue is when you physically break the network cable, not changing anything. This situation is only detected after a relatively long timeout. (You can define your timeout values, but its reasonable to have fairly long time-outs. The bright side is that you can re-connect the cable, and then the communication will continue.) Basically, such wait is always involved. You can experiment with it on a LAN, for example. The work-around would be checking up physical connection with a separate channel and short timeout values (pinging is one of such option), but this strategy would be redundant/wasteful and hardly makes much sense.

I assume that you work with all clients in the same thread (or even work with only one client). However, main issue here is threading. You really need to have at least two separate communication threads on the server side: one thread accepts the new client, another thread reading/writing from/to the network stream. Of course, you need to use appropriate locking for the shared data (such as the collection of connected client or something else related to the clients, such as client-related data).

Please see also my past answers:
an amateur question in socket programming[^],
Multple clients from same port Number[^].

Note my paragraph about graceful disconnection: I try to explain why it hardly makes sense: the application should be ready for all kind of disconnections anyway.

—SA