Detect all computers running a service on a network

Question

I'm trying to write a file synchronization protocol presently (consider it a hobby, I know there are plenty of file synchronizers out there) and I wanted to create a way to automatically sync things across a network. I've heard that this can be accomplished via UDP, but I'm totally oblivious to how to accomplish it.

If I use UDP, will I still have to ping 192.168.X.0 - 192.168.X.255? Or does UDP find a way around that? Is there a way I can in some way bypass firewalls so I don't have to go to each computer on my network and allow incoming traffic to the given UDP port?

Forgive me for being so oblivious on this, this is my first time trying to implement a protocol ;)

Answer 1

You can use nmap to scan hosts to see if they have a service listening on a certain port.

---

There are very few circumstances in which UDP is preferable to TCP:

• UDP doesn't work so well for two-way communications. You have to make up your own query/answer association. Even when you're sending data in one direction, you often want the recipient to acknowledge, which is a datum sent in the other direction.
• UDP isn't reliable. If a packet is lost or duplicated, tough.
• UDP travels by packet. If your packet is too big and is systematically discarded, tough.
• UDP introduces some security issues, such as making distributed denials of service easy. For this reason many firewalls block or severely restrict it.
• Few protocols use TCP, so closed-by-default firewalls just don't let any of it through (apart from DNS, which they tightly constrain).
• UDP doesn't do congestion management. If you flood the network, your packets will be discarded randomly. TCP, on the other hand, will restrict the debit to what the network can bear.

You can send a UDP packet to a machine and see if something answers, of course. You can even send a UDP broadcast and see how far it goes, or send a UDP multicast and hope it arrives.

There are two requirements for a network packet (UDP or TCP) to trigger an action on the destination machine. First, all routers and firewalls on the packet's path must have let the packet through to the destination. Second, there must be an application listening on the destination machine. This could be your synchronizer, or a service starter such as inetd, or a server for a higher-level protocol that you synchronizer would embed into such as HTTP(S) or SSH.

If your packets are blocked by a firewall, then in principle there's no way to go around this. Otherwise the firewall just isn't doing its job. Of course, in practice, firewalls do have holes, for example UPnP (). You're more likely to be able to bypass a firewall over TCP (especially over HTTPS, which firewalls generally can't block selectively so have to let by to permit web browsing) than over UDP.

If there's nothing listening on the destination port, again, you won't be able to take control of the target machine to make it execute your application. (That would be the epitome of insecurity, like some older unpatched versions of Windows.) That's an advantage of piggybacking over a common generalist protocol like SSH: you just have to enable one service, and then you can do what you want over it, including file synchronization.

Answer 2

If you're interested in the local network only, and assuming the client knows the server's port number, the client could broadcast a UDP message, to which the server would reply with a unicast message, thus establishing communications.

Or, you could consider using some existing discovery protocol, such as Bonjour/Zero Conf, or UPnP (Universal Plug 'n Play) to locate your devices.

Firewalls are a separate issue, which in any case you must make sure are open to your discovery packets.