Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!rochester!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: How does the spooler (and wanServer demo) work ?
Message-ID: <49881@cornell.UUCP>
Date: 19 Dec 90 01:53:55 GMT
References: <POP.90Dec18175632@uci12.linus.mitre.org>
Sender: nobody@cornell.UUCP
Reply-To: ken@gvax.cs.cornell.edu (Ken Birman)
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 80

In article <POP.90Dec18175632@uci12.linus.mitre.org> pop@linus.mitre.org (Paul O. Perry) writes:
>
>I created a long_haul.rc file:
>
 1402
 uci12 N:uci12.mitre.org/0
 uci11 N:uci11.mitre.org/0
>
>for now the port is the same as the isis ethernet tcp port in the
>/etc/services file (can I do this ?):
>
 isis            1402/tcp                        # isis
>
>and started the spooler (after I started isis), only to get the
>following error:
>
>uci12: spooler -l long_haul.rc
>ISIS client pid=1872: Error, bad entry in the networks file
>
>It's late and my mind is starting to fade. Where oh where did I go
>wrong ?  

Well, a few things are going on here.  The spooler needs a TCP
port of its own, but it might not complain about the use of 1402 on
all types of machines -- in particular, if ISIS is running with UNIX_DOM
defined, which depends on the version of UNIX, it might not notice
this error.

The second problem is that the lines in the long_haul.rc file need an
extra 0 to terminate the list of connection points.  So, you should
be doing something more like this:
 3456
 uci12 N:uci12.mitre.org/0 0
 uci11 N:uci11.mitre.org/0 0

A third problem, which you won't run into easily, is that the V2.1
release of the spooler has a buggy file transfer protocol in it and
a bug when resetting one of the internal spooler pointers after failure.
Jointly, this makes the system tend to hang when lines go down and come
up during file transfers.  We fixed both problems some time ago; if you
get to the stage where this matters contact patrick@cs.cornell.edu for
a revised copy of util/spooler.c, util/long_haul.c and clib/cl_spool1.c

As for running the wanClient and wanServer programs:

1) Start wanServer on the remote side
   It prints:
   > Wan server ready
   > ... messages about file receptions
2) Start wanClient on the local side
   > wanClient: (c,s,m,x,h,q,d)
   > help
   > c: lh_cbcast
   > s: lh_spool
   > m: move a file
   > x: copy a file
   > h: this help
   > q: quit
   > d: set default transfer directories
   > m
   > File name: /etc/motd
   > destination cluster: [all | local | specific]: uc1l1
   > long haul fragment size (kbytes): 1024
     ... should see messages about transfer ...

Some comments: one of Pat's fixes causes wanClient to print a message
when a transfer is successful and doesn't re-print the prompt, so it
may not be obvious that the client is back in command mode after each transfer.
But, it is.  You can transfer whether the remote is up or not; if not,
files are spooled.

I haven't actually worked with the lh_cbcast and lh_spool test features.
Messac did, though, and they should be fine.

The spooler is in pretty heavy use by at least one major ISIS user (SAIC,
for a nuclear test monitoring and verification system).  With Pat's fixes
it works quite well.  A paper on the use of the spooler in this system
can be found on cu-arpa.cs.cornell.edu in pub/wan.ps.Z

-- Ken