Discover computers on local network with specific open port using .NET

Question

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

Answer 1

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.

Answer 2

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/

Answer 3

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.