我们目前正在研究在.NET Micro框架上运行的120-140个嵌入式硬件设备与服务器之间进行通信的最有效方式。
每个嵌入式设备都需要通过TCP实时发送并从服务器请求信息。
我的问题是：初始化到服务器的140个TCP连接，然后挂起这些连接，或者为每个进出设备的请求初始化新连接会更好吗？坚持和管理140个TCP连接会给服务器带来很大压力吗？
当服务器检测到数据库中的新数据时，它需要将此新信息发送到1 .. *设备（信息针对特定设备），如果我保持140个连接，我需要查找每次我需要发送信息而不是仅发送到IP时的正确连接：与新数据相关联的PORT。
我想另一个可能是愚蠢的问题是它实际上可能会挂在单个端口上的140个TCP连接上吗？
任何建议/意见表示赞赏！
答案 0 :(得分：3)
通常，您最好尽可能长时间地保持连接。如果每次设备发送消息时每个设备都打开一个连接，那么最终可以有效地执行服务器操作，因为它最终会在TIME_WAIT状态下占用许多套接字占用其表中的空间。
我在一个系统上工作，其中有许多客户端与服务器通信，虽然可以定期打开和关闭，但仍然可以更好地维护连接（并在连接丢失时重新建立连接）需要发送新消息）。您可能最终需要编写稍微复杂的代码，但我发现在服务器上减少负载是值得的。
现代操作系统可能比我实际遇到的DoS效果具有更大的缓冲区，但从根本上说，使用大量连接并不是最佳选择。
在客户端，事情会变得相对复杂，尤其是当设备倾向于透明地睡眠到应用程序时，因为这意味着当应用程序认为它们仍处于打开状态时连接会超时。当我们这样做时，我们最终得到了相对复杂的网络代码，因为我们需要处理套接字可能（并且会）失败的事实，我们只需要设置一个新连接并重新尝试发送消息。你只需将这些代码放入你的库中，一旦完成就忘了它。
实际上在实践中我们的初始应用程序有更复杂的代码，因为它处理的是一个网络库，它半知道设备的停止启动性质并尝试重新发送失败的消息，有时意味着相同的消息被送了两次。我们最终在顶部进行了额外的通信层，以确保重复被拒绝。如果您正在使用C＃或常规BSD样式的套接字，尽管我猜测你应该没有这个问题。这是一个专有的库，可以管理重新连接，但是会导致重新发送令人头疼，并且默认超时不合适。
答案 1 :(得分：2)
您通常可以将超过140个“客户端”连接到服务器（具有不错的网络/硬件/ RAM）...
我建议总是用真实场景（负载等）来测试这类事情，因为有网络（性能，稳定性......），硬件（服务器RAM等）和SW（有什么方面）。服务器究竟做什么？）只能由你检查。
根据协议的不同，您甚至可以在其中设置一些超时/重新连接机制。
你的意思是非常快 - 只需用ConcurrentDictionary来保存IP所需的信息：PORT作为密钥（假设服务器在完整的.NET 4上运行）。
对于某些参考文献，请参阅：
编辑 - 根据评论：
保持TCP / IP连接不需要太多处理客户端...它需要一点内存。我建议做一个小测试（1-2个客户）来检查你的具体情况的假设。
答案 2 :(得分：2)
如果您正在谈论具有硬件设备的系统，那么我建议每次客户端完成发送数据时关闭连接。
为了确保客户端从服务器获得某些更新，客户端可以等待5秒钟，以便从服务器到达任何数据。如果在此时间范围内/之前接收数据，则关闭连接并处理数据。如果没有，请关闭连接并在发送下一组数据后等待。
这样缩放变得更容易。保持连接打开总是会导致资源紧张，除非是心率监测器，氧气供应监控器等一些救生设备，否则我认为没有必要。