dws@uafcseg.uucp (David W. Summers) (10/01/89)
I have seen several references to it being "virtually impossible" to modify UUCP to do bidirectional transfers. What I want to know is if the people saying these things have actually looked at the source code for UUCP? If you have and you think about it a little bit, I *THINK* you will find that it is NOT virtually impossible. In fact, from perusing the UUCP source code (thanks to having a Unix 3.1 source liscence), I have found that it appears to be (maybe not trivial but) possible to add bi-directional UUCP file transfer. I have even implemented such a beast, although my packet error checking is not functioning as well as I would like, and currently if I have very long transfers, I eventually get some un-recoverable errors. However, this has nothing to do with my bi-directional transfer concept, but merely the paticular error checking algorithm I employ (can anyone help me on this?). I will even post my protocol (which I call 'b' (that can be easily changed if need be)) if anyone is interested. The UUCP source code seems to be very well modularized, which was a TREMENDOUS help in getting this stuff to work at all. Basically what I did was to define my own 'b' protocol routines that interface to main UUCP calling routines just like any other protocol. The five main interface routines are 'bturnon', 'bturnoff', 'bwrmsg', 'brdmsg', 'bwrdata', and 'brddata'. These are the "high level protocol" routines that UUCP calls whenever it talks via the 'b' protocol. 'bturnon' basically creates 3 other processes: 1 Reverse Role process and 2 controller processes. The two controller processes are a demultiplexor whose only job is to read incoming packets, checking for errors, and send them to the master/slave/multiplexor processes. The multiplexor process reads messages and data from the master/slave/demultiplexor processes and multiplexes them out as packets onto the communications line. All these processes are duplicated on the other computer, which brings the total number of processes to 8. Here is a diagram: ********** ****************** * Master * <----- * De-multiplexor * <------- Communication Input ********** ****************** | | | | | | ---------------- | | |-------------- | | | | V V V ********** ****************** * Slave * -----> * Multiplexor * --------> Communication Output ********** ****************** This arrangement is duplicated on the other computer. Variable length packets are sent and received on each communication input and output line between the two computers. Each packet is numbered and contains a 32 bit CRC for the packet as well as a 32 bit CRC for the data. The protocol I'm using is a streaming protocol so that if there are just a few recoverable errors then the receiving side continues to accept incoming packets out of order until it can get stuff in order. It will send a NAK for a packet that it missed. As I have implied (I hope), I am very interested in corresponding with anyone else who is interested in this same topic and I would be glad to share my code with anyone who thinks they can use it. (Just don't try to take credit for my code for yourself!) I have it working, but, like I said, my error correction scheme evidently is not perfect (although I don't know how it messes up). I would be VERY interested in sharing code with someone who could help me figure out a better protocol (ZMODEM?) or something like that and/or help me figure out what is wrong with my error checking/correcting. Please be warned that this is the very first file transfer protocol that I have ever attempted to write!!!!!!! David Summers "Be Original! Drink Dr. Pepper like everyone else!" (dws@uafcseg.uark.edu)