Uucp/uux through networks

[Michael Meissner]

Fellow Netters:

    I am currently looking at trying to get uucp to move files through internal
networks, of various capabilities, and would like input as to any problems that
I haven't thought about.  This has to work without modifing uucp, or any of the
programs that use uucp as a transport mechanism.  To further complicate things,
I personally cannot look at the source to UNIX licensed material, even though
other parts of Data General do have source capabilities (in fact, supply the
uucp for DG/UX (native UNIX tm), and MV/UX (hosted on top of the AOS/VS oper-
ating system)).  Finally, this is your classic underground project, as my
normal job is supplying the C compiler.

    My home machine (oz) is located in Westborough, MA.  I hope to add oz to
the usenet as the machine dg_oz.  It runs Data General's proprietary operating
system AOS/VS, and our hosted UNIX MV/UX.  In terms of networking, it uses
an X.25-based networking scheme to communicate to other AOS/VS systems.
Through two gateways, it is tranparently connected to rtp33 in Raleigh, North
Carolina, which is also running AOS/VS and MV/UX.  Rtp33 is connected via
TCP/IP to our native UNIX system rtp47, as well as being directly connected
via RS-232 lines for uucp.  Due to the distance and tight budgets, it is not
feasible to do more than very infrequent polling via the public dial network.
Also, I cannot connect the remote machines via something like a pty, due
to various problems, particularly when crossing from one operating system
to another.  Directly connecting rtp33 or rtp47 to oz via a direct connect
RS 232 is obviously infeasible, since we are ~750 miles apart.  The connection
looks like:

machine:	oz		rtp33		rtp47
operating sys.	AOS/VS		AOS/VS		DG/UX
UNIX		hosted sys V.2	hosted sys V.2	native sys V.2 and BSD 4.2

		  XODIAC (X.25)       (TCP/IP)	     (the world through uucp)
		x <------------> x <------------> x <------ ...
				 \		 /
				  \   (RS-232)  /
				    <---------->


    My scheme consists of three parts:

    1)	Respooling of the uucp/uux work files.  A batch (read cron) job gets
	started off at regular intervals, and looks for interesting uucp work
	files.  The L.sys file specifies never to call any networked uucp
	system, so that the work files are just spooled to /usr/spool/uucp.
	Any work files for a networked system will be bundled up into a
	separate file (tenatively with some prefix like S. or B.).  If there
	are no errors in bundling up the file, the relavant work files are
	deleted.  The bundled file will contain a length indicatation, and
	a checksum, so the remote system can know if the entire file is
	there.

    2)	The bundled file is then sent to the remote system, using whatever
	network connects the two machines (ie, XODIAC for AOS/VS <-> AOS/VS,
	TCP/IP for AOS/VS <-> DG/UX, possibly things like through a kermit
	server, mag tape, etc. if the need arises).  A separate spool directory
	is used to prevent mismatches.  Also to prevent possible collisions
	with the sequence number which is embedded in the filename, I am think-
	ing of having separate spool directories for each host.  If the trans-
	mission went without errors, the bundled file will be deleted, other-
	wise the next incarnation of the program will attempt to send it.

    3)	After sending files to remote systems, the program then looks in the
	spool directories, to see if anything new was sent to the local host.
	If we do have something new, the bundled file will be unbundled, and
	acted upon (ie, doing something like firing up rnews or rmail).


    According to the System V uucp administrator's manual, it looks like there
are three types of files queued up by uucp/uux:

    C.<sys><xx><seq>
    D.<sys><xx><seq>
    X.<sys><xx><seq>

where:

    <sys> is either the remote or local system name (6 chars max)
    <xx>  seem to be random characters, probably involved with priority
    <seq> is a 4 digit sequence number.  All files associated with a job have
	  the same sequence number.

The C.* file is the main work file, with separate lines indicating
whether to send or receive a file, and fields (separated by whitespace)
indicating various things.  To send a file to a remote system, the
following fields are defined:

    Field 1:	"S"
    Field 2:	source file, including ~user convention
    Field 3:	destination file
    Field 4:	user's login name
    Field 5:	options preceded by "-"
    Field 6:	data file in spool directory
    Field 7:	file mode bits (in octal)

The format for receiving a file is:

    Field 1:	"R"
    Field 2:	source file
    Field 3:	destination file
    Field 4:	user's login name
    Field 5:	options preceded by "-" (-d and -mfile)

The D.* file(s) are the data files to be sent to the remote system.

The X.* file indicates work to be done on the remote system.  Each line is a
separate command, and fields are separated by whitespace.  Commands that I
know about are:

    Field 1 Field 2	Field 3				Role

    "U"	    username	sys which spooled work		send msgs back
    "F"	    filename	local-name (optional)		required file
    "I"	    filename					specify input file
    "O"	    filename	remote system			specify output file
    "C"	    command	arguments...			execute command


The following questions come to mind:

    1)	What are the other schemes used for encoding the work files (BSD and
	hony danbar)?  Different grading/sequence numbers, different spool
	directories, different types of work file, different fields within
	the work files, etc.

    2)	What other options might appear within field #5 of C.* files?

    3)	What other lines might occur within C.* and X.* files?

    4)	For sending files via TCP/IP, is the FTP socket interface documented,
	or should I actually popen ftp, and send input to it.  If the later,
	is there any universal means of determing whether a file was sent
	without error, or must I interpret the output of ftp to determine if
	everything went ok?

    5)	XODIAC has facilities for restarting transfers of files from check-
	points which crashed in the middle of sending files back and forth.
	Does TCP/IP have facilities like this or would I have to reinvent the
	wheel, or just restart the entire transfer?  In particular, which
	batched news around 50K per batch, I think murphy will act up.

    6)	Has this been done before (making a batch oriented uucico, which cannot
	run the remote commands from the sending process)?  If so, any
	sage words of advice?


Please direct useful information to me, or to the news system.  If enough
useful information gets deposited in my mailbox and others ask for it, I
will post a summary to the net.  Please keep your flames to yourself.  At
this time, I cannot promise to send the resulting source code out, due to
various legal agreements.

	Michael Meissner
	Data General Corporation
	MS. E111
	Westborough, MA, 01580
	617-366-8911 x3292
	...{ ihnp4, decvax }!mcnc!rti-sel!rtp47!meissner