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.