C# 保持140个TCP连接？

我们目前正在研究在.NET Micro framework上运行的120-140个嵌入式硬件设备与服务器之间进行通信的最有效方式

每个嵌入式设备都需要定期向服务器发送和请求信息，所有这些信息都需要通过TCP实时发送

我的问题是：是否最好初始化140个到服务器的TCP连接，然后保留这些连接，或者为每个到设备和从设备发出的请求初始化一个新连接？保持和管理140个TCP连接会给服务器带来很大的压力吗

当服务器检测到数据库中的新数据时，它需要将此新信息发送到1..*设备（信息针对特定设备），如果我保留140个连接，则每次需要发送信息时，我都需要查找正确的连接，而不是仅发送到与新数据关联的IP:端口

我想另一个可能愚蠢的问题是，在一个端口上是否可能挂起140个TCP连接

---

欢迎提出任何建议/意见

您通常可以将140多个“客户机”连接到服务器（即使用适当的网络/HW/RAM）

我建议总是用真实的场景（负载等）来测试这类事情，以做出决定，因为网络（性能、稳定性等）、硬件（服务器RAM等）和软件（服务器到底做什么？）等方面只能由您检查

根据协议的不同，您甚至可以/应该在其中加入一些超时/重新连接机制

您所说的查找速度非常快—只需使用

ConcurrentDictionary

以IP:PORT作为键保存所需的信息（假设服务器在完整的.NET4上运行）

有关一些参考资料，请参见：

编辑-根据评论：

---

保持TCP/IP连接不需要太多的客户端处理。。。它需要一点内存。我建议进行一个小测试（1-2个客户端），以检查您的特定情况下的假设。

如果您谈论的是带有硬件设备的系统，那么我建议在客户端每次完成发送数据时关闭连接

为了确保客户机从服务器获得一些更新，客户机可以等待5秒钟，等待任何数据从服务器到达。如果在此时间范围内/之前收到数据，则关闭连接并处理数据。如果没有，请关闭连接并在发送下一组数据后等待

---

这种方式使缩放变得更加容易。保持连接打开总是会导致资源紧张，在我看来没有必要，除非它是一些救生设备，如心率监视器、供氧监视器等。

一般来说，您最好尽可能长时间地保持连接。如果您让每个设备在每次发送消息时都打开一个连接，那么您就可以有效地关闭服务器，因为服务器在等待时间状态下会有大量套接字占用其表中的空间

我曾在一个系统上工作过，在这个系统中，有一群客户机与服务器对话，虽然可以定期打开和关闭它们，但最好还是保持连接（当连接中断并需要发送新消息时重新建立连接）。您可能最终需要编写稍微复杂一点的代码，但我发现，为减少服务器上的负载而付出的努力是值得的

现代操作系统的缓冲区可能比我实际遇到DoS效应的操作系统的缓冲区大，但从根本上说，使用大量这样的连接并不是最好的主意

在客户端，事情可能会变得相对复杂，尤其是当设备倾向于以对应用程序透明的方式进入睡眠状态时，因为这意味着当应用程序认为连接仍处于打开状态时，连接将超时。当我们这样做时，我们最终会得到相对复杂的网络代码，因为我们需要处理套接字可能（并且会）失败这一事实，当然，我们只需要建立一个新的连接并重新尝试发送消息。您只需将这些代码塞进您的库中，并在完成后将其忘掉

---

实际上，我们最初的应用程序有更复杂的代码，因为它处理的是一个网络库，它半意识到设备的停止-启动性质，并试图重新发送失败的消息，有时意味着相同的消息被发送了两次。我们最终在顶部做了一个额外的沟通层，以确保副本被拒绝。如果您使用的是C#或常规BSD样式的套接字，那么我猜您不应该有这个问题。这是一个管理重新连接的专有库，但在重新发送时引起了麻烦，而且是不适当的默认超时。

那么长时间运行这么多连接是否会受到惩罚？惩罚是“相对的”-这取决于您将其与什么进行比较。。。OP说他们需要定期在客户端和服务器之间实时交换数据。。。打开和关闭这么多的连接可能会影响性能并导致一些问题，因此：相比之下，我怀疑保持连接是可以的。添加了一个测试建议。Ok有意义。谢谢你的回复：D。谢谢你的链接和评论，这将在.NET3.5下运行。我们不太担心服务器上的负载，更关心的是保持连接会对嵌入式设备产生什么影响，因为它在处理能力方面非常有限。@Adrian保持TCP/IP连接本身不是处理密集型的，它通常需要一些内存。。。除非你在计算嵌入式设备上的CPU周期和位，否则我认为这不是一个真正的问题。。。从我的观点来看，通过一个小测试（仅一个或两个clie）来评估这一点应该很容易