From: meissner@rtp47.UUCP (Michael Meissner) Subject: Uucp/uux through networks Date: 8 Nov 85 01:45:30 GMT Followup-To: net.unix-wizards Keywords: uucp To: info-unix@brl-tgr.arpa 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. D. X. where: is either the remote or local system name (6 chars max) seem to be random characters, probably involved with priority 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