Re^4: Fastest way to determine whether a specific port is open via a Socket

Thanks a lot for the reply. What i am doing is a lpr queue. I have several hosts running WinLPD - an LPD alternative for Windows 98. On other hand I have two applications that are supposed to print jobs to the remote hosts (It is a point of sale system). The whole idea is to manage e bad queue for the jobs that are not going through. At the same time the issue is with the jobs going to hosts that are "alive". Looked around for a lpr queue but there is nothing freely available, which is why I decided to do this myself and then host it on Source Forge as a tool, as there is a need for Windows based LPR queue software that is free of charge.

I will have a look at Parallel::ForkManager and try and utilize it in the processing of the bad queue. The jobs in my case are very small text files (mainly customers slips). Which makes the processing of a single job very quick... except the case when the host on the other side is not responding and I need to retry this job until it becomes available. Using of threads makes the biggest sense for now.

The process that I am talking about looks like this:

<APPLICATION> -> <JOB_FILE> -> <QUEUE_PROCESSOR-LPR> -> <REMOTE_LPD_PRINTER>

Comment on Re^4: Fastest way to determine whether a specific port is open via a Socket

Replies are listed 'Best First'.
Re^5: Fastest way to determine whether a specific port is open via a Socket by jbert (Priest) on Oct 30, 2006 at 17:10 UTC
Ah, OK. Good luck. 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.	[reply]

Replies are listed 'Best First'.

Re^5: Fastest way to determine whether a specific port is open via a Socket
by jbert (Priest) on Oct 30, 2006 at 17:10 UTC

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.

[reply]