WCF 双工服务和 TCP 端口耗尽
我正在努力解决这个问题。 我正在制作一个特定于业务的消息传递应用程序，它将通过 WCF（无 VPN，整个网络）将 5000 到 10,000 台计算机连接回我们的数据中心。 它主要用于警报，我需要能够直接向特定客户端发送消息，WCF 允许我使用 Duplex 合约完成所有这些工作，但是对于如此多的客户端，它让我考虑最大化 TCP 端口空间65535 个端口。
我假设所有入站连接都将通过我选择的任何端口进入，但返回客户端的出站连接将各占用一个端口。 我很好奇 WCF 端口共享服务是否可以解决此问题，或者它是否只是 65535 端口到 IP 地址？ 就此而言，MSN Messenger 等如何处理这种情况。 当然，我可能永远无法达到这个目标，但至少我正在迈入这个境界。
或者，服务端的 WCF 双工合约是否在客户端的持续时间内为回调保持打开端口，或者释放它？
I am trying to wrap my head around this. I am making a business specific messaging application, it is going to connect between 5000 and 10,000 machines back to our datacenter via WCF (no vpns, all over the net). It is mainly for alerts and I need to be able to send message direclty to specific clients, and WCF allows me to do all of this with a Duplex contract, but with this many clients it got me thinking about maxing out the TCP port space of 65535 ports.
I am going to assume that all inbound connections are going to come in over whatever port I choose, but outbounds back to the clients are going to take one port each. I am curious if the WCF port sharing service does anything to solve this issue or if its just 65535 ports to an IP address? For that matter, how does MSN Messenger and the like deal with this situation. Granted I may never reach it, but I am getting in the realm at least.
Or does the WCF duplex contract on the service end keep the port open for the callback for the duration of the client, or does it release it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在高打开/关闭事务环境（例如服务非持久连接的套接字服务器）中，仍然很容易耗尽默认 TCP 堆栈。
默认的 TIME-WAIT 延迟加剧了这种情况 - 套接字在回收之前必须关闭的时间 - 默认为 90 秒（如果我没记错的话）
要从我的其他线程之一回收一些位 - 有一个一堆可以调整的注册表项 - 建议至少创建/编辑以下注册表项
MSDN 和 MSDN 上有大量文档 有关这些按键功能的 Technet。 例如
对于套接字服务器应用程序（例如 SQL、Biztalk、IIS 等）调整这些键是很常见的。
It is still pretty easy to drain the default TCP stack in a high open/close transaction environment e.g. socket server serving non-persistent connections.
This is exhacerbated by the default TIME-WAIT delay - the amount of time that a socket has to be closed before being recycled - this defaults to 90s (if I remember right)
To recycle some bits from one of my other threads - there are a bunch of registry keys that can be tweaked - suggest at least the following keys are created/edited
Plenty of docs on MSDN & Technet about the function of these keys. e.g.
It is pretty common to tweak these keys for socket server applications e.g. SQL, Biztalk, IIS etc.
我认为每个端口实际上是 DestinationTCPAddress 和端口号的组合 - 所以你不会用完。
即，您可以在同一个源端口上与多个订阅者进行通话。 这只是能力问题。
I think each port is actually a combination of DestinationTCPAddress and Port Number - so you won't run out.
I.e. You can have several subscribers all being talked to on the same source port. It just becomes a matter of capacity.
如果这些连接都是并发的，那么您需要确保您的防火墙可以同时处理那么多连接。
状态防火墙需要记录通过它们的每个正在进行的连接，以便它们可以判断后续数据包是否被允许。 小型防火墙的会话限制为数百个的情况并不罕见。
If these connections are all going to be concurrent then you will need to ensure that your firewall can cope with that many connections at once.
Stateful firewalls need to record each ongoing connection going through them so that they can tell whether subsequent packets are permitted. It's not uncommon for small firewalls to have session limits in the hundreds.
连接按源地址、目标地址、源端口、目标端口进行区分（至少在 IP 层）。 操作系统对最大连接数的某种限制可能会成为一个问题，但不要沉迷于端口号本身是任何实际限制的想法。
Connections are distinct (at least at the IP layer) by source address, and destination address, source port, destination port. Some sort of OS limitation on the maximum number of connections may become an issue, but don't get hung up on the idea that the port numbers themselves are any sort of realistic limitation.