Various ways to implement a daemon that pings remote hosts.

David Blume David Blume first commit. e73f511 @ 2019-07-05 20:08:07
images first commit. 2019-07-05 20:08:07
LICENSE.txt first commit. 2019-07-05 20:08:07
README.md first commit. 2019-07-05 20:08:07
long_lived_looping_workers.py first commit. 2019-07-05 20:08:07
long_lived_worker_queue.py first commit. 2019-07-05 20:08:07
short_lived_workers.py first commit. 2019-07-05 20:08:07
README.md

python_pinger

These are different approaches to how one might implement a daemon to repeatedly ping multiple hosts to see if the network is up.

Single Threaded

This is the most naive implementation. For each ping host, the main process thread pings them one at a time, and prints any changes.

Single Threaded Pings

Upsides

Really simple code.

Downsides

Since the pings are serialized, one long timeout from one host could affect detecting a problem at another host.

Long Lived Workers Consuming from Queue

Raymond Hettinger's PyBay 2018 Keynote uses the queue module to send data between threads, so I thought I'd make a version of the pinger that did the same.

long_lived_worker_queue.py

Long Lived Queue Workers

Upsides

Multi-threaded ping calls won't block each other.

Downsides

The ping tasks read from, and write to a shared dictionary. (Reading and updating the last status.)

Short Lived Workers

Short Lived Workers

short_lived_workers.py

Upsides

The worker tasks aren't in memory if they're not doing anything. So usually a smaller memory profile.

Downsides

The ping tasks still read from, and write to a shared dictionary. (Reading and updating the last status.)

Long Lived Looping Workers

Long Lived Looping Workers

long_lived_looping_workers.py

Upsides

No more race conditions! The worker threads mind their own business.

Downsides

The worker threads remain in memory.

Is it any good?

Yes.

Licence

This software uses the MIT license.