jr@amanue.UUCP (Jim Rosenberg) (07/09/89)
I asked this question once before & got a thundering silence -- sorry if I
missed any replies, but I *still need to know*. How can I guarantee that uucp
will deliver jobs to a remote system in the order in which they were queued?
More specifically, how can I issue a series of uux requests and be sure that
the uuxqt at the remote end will execute them in the same order? I have HDB
at one end, and by the time the system is in production will have HDB at the
other end too. The system will be Sytem V.3 in production, if that makes any
difference.
My *very strong impression* is that uucico simply uses the ordering you would
get by doing an ls -f C.* on the spool directory. This is not at all
guaranteed to give the same order as ls -rt C.*, which is what I'd like.
If this suspicion is correct, then I could try to solve my problem by filling
up "holes" in the spool directory before issuing the uux request -- *PROVIDED*
I could completely lock any uuoids in the interim which might remove any files
from the spool directory. (I really don't care if some other process sneaks
in "intervening" jobs -- that doesn't matter. The process that will create
the jobs I'm concerned about has its own locking that guarantees only one
instance can run at once.) For old-style uucp this is a dire pain, since all
sites share the same spool directory. That would mean locking uucp across
all sites. But for HDB I could at least lock the site in question, fill up
holes in the spool directory, then unlock the site. Is this good enough? Is
there a simpler way?
Somehow this makes me nervous. Does the cleanup daemon honor a site lock?
Tampering with directory slots like this seems like a real kludge, and there's
no way I can think of to lock the directory in a truly safe way that's
guaranteed to be reliable.
Not to mention the problem that even if I can guarantee that uucico on the
sending end sends jobs in chronological order, I still don't know if uuxqt on
the receiving end will *run* them in the same order! If uuxqt runs jobs in ls
-f order for the receiver's spool directory, then no amount of clever fakery
on the sending end will help one wit. If this is how uuxqt works then I fear
there may simply be no way to do this.
Aargh, am I asking for the impossible? This seems like such a straightforward
thing to want to do, I'd have thought this issue would have been old hat. I
notice news articles all the time where a reply has a lower article number
than the article to which it's replying; I wonder how much of that is from
uucico delivering jobs "out of order".
Any help appreciated.
--
Jim Rosenberg
CIS: 71515,124 decvax!idis! \
WELL: jer allegra! ---- pitt!amanue!jr
BIX: jrosenberg uunet!cmcl2!cadre! /grr@cbmvax.UUCP (George Robbins) (07/11/89)
In article <454@amanue.UUCP> jr@amanue.UUCP (Jim Rosenberg) writes: > I asked this question once before & got a thundering silence -- sorry if I > missed any replies, but I *still need to know*. How can I guarantee that uucp > will deliver jobs to a remote system in the order in which they were queued? > More specifically, how can I issue a series of uux requests and be sure that > the uuxqt at the remote end will execute them in the same order? I have HDB > at one end, and by the time the system is in production will have HDB at the > other end too. The system will be Sytem V.3 in production, if that makes any > difference. I'm not sure you can do what you want directly. The traditional forms of uucp had a "sequence file" what was somehow intended to allow uucp to detect when a transfer got "lost". This feature is almost entirely unused. I don't know that it would do quite what you want, or whether is has survived in any usable form in HDB. Most likely you will have to implement some kind of queueing system, where the uux requrests simply drop that data into some kind of spool queue and then some task has to analyze the queue and see which tasks have enough input to run or which might need to request a resend or some nature of manual intervention. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)