FYI, one approach which some mail systems use is to keep "known bad" and "just received" in different queues.
The idea here is that any time you see something in the just-received queue it is likely to be good (most requests are good) and so you schedule it immediately. If it fails, you move it to the 'bad' queue, where you have a different policy (perhaps a simple round-robin where one process tries each 'bad' in turn, with a short sleep before walking the queue again).
These can either be logical (say, two different @arrays referring to the same directory root) or physical (actually have two different root dirs). One characteristic of the latter is that the 'badness' state persists over restart. This can either be good or bad, depending on what behaviour you want. There's certainly something to be said for rebooting forgiving the past signs of unavailable printers.
There are a *lot* of similarities to the SMTP MTA problem - e.g. keeping per-destination availability info to avoid repeated connections to a known-dead host. Overkill for v1.0, but you might get some good ideas from reading the FAQs, docs or code for one of the good SMTP MTAs, say Exim.
In reply to Re^5: Fastest way to determine whether a specific port is open via a Socket
by jbert
in thread Fastest way to determine whether a specific port is open via a Socket
by avo
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |