持续140个TCP连接？

Question

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

每个嵌入式设备都需要通过TCP实时发送并从服务器请求信息。

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

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

我想另一个可能是愚蠢的问题是它实际上可能挂在单个端口上的140个TCP连接上吗？

任何建议/意见表示赞赏！

Answer 1

通常，您最好尽可能长时间地保持连接。 如果每次设备发送消息时每个设备都打开一个连接，那么最终可以有效地执行服务器操作，因为它最终会在TIME_WAIT状态下占用许多套接字占用其表中的空间。

我在一个系统上工作，其中有许多客户端与服务器通信，虽然可以定期打开和关闭，但仍然可以更好地维护连接（并在连接丢失并需要新消息时重新建立连接）被发送）。 您可能最终需要编写稍微复杂的代码，但我发现在服务器上减少负载是值得的。

现代操作系统可能比我实际遇到的DoS效果具有更大的缓冲区，但从根本上讲，使用大量连接并不是最好的想法。

在客户端，事情可能变得相对复杂，特别是当设备倾向于透明地睡眠到应用程序时，因为这意味着当应用程序认为它们仍处于打开状态时连接会超时。 当我们这样做时，我们最终得到了相对复杂的网络代码，因为我们需要处理套接字可能（并且会）失败的事实，我们只需要设置一个新连接并重新尝试发送消息。 你只需将这些代码放入你的库中，一旦完成它就会忘记它。

事实上，在实践中我们的初始应用程序具有更复杂的代码，因为它处理的是一个网络库，它半知道设备的停止启动性质，并试图重新发送失败的消息，有时意味着相同的消息被发送两次。 我们最终在顶部进行了额外的通信层，以确保重复被拒绝。 如果您正在使用C＃或常规BSD样式的套接字，尽管我猜测你应该没有这个问题。 这是一个专有的库，管理重新连接，但导致重新发送令人头痛，并且它是不合适的默认超时。

Answer 2

您通常可以将超过140个“客户端”连接到服务器（具有良好的网络/硬件/ RAM）...

我建议总是用真实场景（负载等）来测试这类事情，因为有网络（性能，稳定性......），硬件（服务器RAM等）和SW（服务器究竟做什么）等方面？）只能由您检查。

根据协议，你可以/甚至应该在那里放置一些超时/重新连接机制。

您的意思是非常快 - 只需使用ConcurrentDictionary来保存IP所需的信息：PORT作为密钥（假设服务器在完整的.NET 4上运行）。

有些参考资料请参阅：

• http://msdn.microsoft.com/en-us/library/dd287191.aspx
• http://geekswithblogs.net/BlackRabbitCoder/archive/2011/02/17/c.net-little-wonders-the-concurrentdictionary.aspx

编辑 - 根据评论：

坚持TCP / IP连接并不需要客户端处理太多...它需要一点内存。 我建议做一个小测试（1-2个客户）来检查你的具体情况的假设。

Answer 3

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

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

这种方式缩放变得更容易。 保持连接打开总是会导致资源紧张，除非是心率监测器，氧气供应监视器等一些救生设备，否则我认为没有必要。