使用 .NET 发现本地网络上具有特定开放端口的计算机
我需要“发现”运行我的 Windows WCF 服务的本地计算机，以便我可以与它们通信。现在您必须手动输入 ip 地址：端口组合，但我想要一个（网络？）应用程序来监视运行该服务的计算机并对其进行报告。
当我尝试连接到无效的 ip/端口时，它需要“永远”超时，因此检查本地网络上的所有 ip 是不可行的。有没有一种快速的方法来发现哪些机器打开了端口（所有这些机器在防火墙中都有针对该特定端口的漏洞）
TIA
I need to "discover" local computers running my windows WCF service, so I can talk to them. Right now you have to enter manually the ipaddress:port combination, but I would like to have a (web?) application that monitors the machines running the service and reports on it.
When I try to connect to an invalid ip/port it takes "forever" to timeout, so it's not feasible to check all the ip on my local network. Is there a quick way to discover which machines have the port open (all of them have the hole in the firewall for that specific port)
TIA
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我已经这样做过好几次了。只需将超时值设置得很低即可。
另外，如果它是一台真实的机器，但没有打开端口，它应该会很快失败。如果您正在进行子网扫描，那么，是的，您需要有一个（比如说）1 秒的超时。
多线程扫描 - 这是代码
编辑的一件有趣的事情：我找不到我的代码。这是其他人的解决方案的链接
http://social.msdn.microsoft.com/forums/en-US/netfxnetcom/thread/c8161442-61b5-4840-999b-5bb36bda0b6d/
I have done this several time. Just set the timeout value very low.
ALso if its a real machine but without the port open it should fail fast anyway. If you are doing a subnet sweep then, yes, you need to have a (say) 1 second timeout.
Multi-thread the sweep - this is a fun thing to code
edit: I cant find my code. here is link to solution from somebody else
http://social.msdn.microsoft.com/forums/en-US/netfxnetcom/thread/c8161442-61b5-4840-999b-5bb36bda0b6d/
您能否将客户端配置为联系 Web 应用程序并报告其正在运行 WCF 服务的位置？
这需要 Web 应用程序在不会更改的已知计算机上运行。
could you have the client configured to contact the web app and report with it's location that it is running your wcf service?
that would require the web app to be running on a known machine that doesnt change.
为什么不让他们使用多播来经常广播“HELLO”数据包。当然，这是假设您的场景中可以使用多播并且您不跨路由域进行通信。只需使用“HELLO”数据包内容（例如 ipv4 单播地址）即可确保您知道应该与什么对象通信。当然，您不需要使用多播，您只需发送广播到 255.255.255.255（这不是一个复杂的任务），然后监听这些消息。这样做的好处是您还可以启用端口协商。例如，如果您的应用程序通常绑定到一个端口，但该端口不可用，它可以自动选择一个端口并让您知道它绑定到哪个端口。避免手动配置维护和相关的麻烦。天啊，它甚至可以使用广播来发送消息并检查是否收到它。如果没有，请发出警报让系统管理员知道。
我使用类似的方法来管理软开关（语音）的测试工具，并且效果非常好。
当然，我可能对此非常不以为然。只是在这里跳出框框思考。
Why not make them use multicast to broadcast a "HELLO" packet every so often. This is assuming of course that multicast is available in your scenario and your not talking across routing domains. Simply use the "HELLO" packet contents such as ipv4 unicast address to ensure you know what you should be talking to. Of course you don't need to use multicast, you can just send a broadcast to 255.255.255.255 which is not a complex task and then listen for these messages. The benefit of this is that you could also enable negotiation of the port. For instance, if your application generally binds to a port but this port is unavailable, it can automatically choose a port and let you know what port it is bound to. Avoids manual configuration maintenance and headaches involved. Hell, it can even use broadcast to send a message and check if it received it. If it doesn't, fire off an alert letting the systems administrator know.
I use something along these lines for managing test harnesses for soft switches (voice) and it works very well.
Of course, I could be very much off on this. Just thinking out off the box here.