Given your needs, I think that pg hit the nail on the head in his post when he suggested UDP.

To avoid the terminology problem, lets call the single machine the collector and the 100 machines emitters.

Have the collector listen on a single UDP socket for packets from the emitters. Each time it gets a packet it updates that emitters status in a hash with a timestamp. Inside the listen loop, have the collecter run through the list looking for an emitter with a timestamp more than a minute old. If it finds one, have it attempt a TCP connect to that emitter and request the status, if the connect fails or the status isn't recieved, raise the alarm.

If you have the emitters send their status at say twice the frequency of the timeout period, then you allow for some packets to get dropped without raising false alarms.

With this model, there is no need for child processes, reaping or hundreds of connections and ports. Just one listening UDP port and a low-frequency, transient TCP connection that is only used when the network gets flaky. You might benefit from making that a child process, though if you are running on a threaded perl, it would make more sense and use less resources to use a thread.

On a threaded Perl, you could also have the verify timestamps loop run in a seperate thread using read-only access to the hash, whilst the listening loop did the updating without needing much in the way of serialisation.