Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!urlichs From: urlichs@smurf.sub.org (Matthias Urlichs) Newsgroups: comp.mail.uucp Subject: Re: What should a new UUCP protocol do? Message-ID: Date: 11 Nov 90 19:05:44 GMT References: <+2m8g2.lb1@smurf.sub.org> Organization: University of Karlsruhe, FRG Lines: 48 In comp.mail.uucp, article , curt@cynic.wimsey.bc.ca (Curt Sampson) writes: < < Zmodem also has provisions for a restart on an interupted transfer < (i.e., when you hang up or get hung up upon for whatever reason and < then call back). It's just like a NAK in the transfer, actually. You < just hand it a byte offset into the file and tell it to go. < < > One problem that you're not going to cure with this is that if you have a < > full duplex link, about half the bandwidth is wasted. Fixing this would < > probably require major mods to the uucico's involved. < < My copy of the uucp protocol description seemed to imply rather < strongly that it would be possible to have a uucp session going in < each direction. Obviously, the ones currently in use don't do this. < It would be very nice to have, though. < The g protocol's packet handler (for those with source code: pk[01].c) would support bidirectional traffic. However, neither uucico itself nor the uucico-to-protocol driver interface (cntrl.c, [fget]io.c) allow this. Implementing bidirectional transfer seems to imply either a major rewrite, major hacks inside the protocol driver, implementing a bidirectional data stream (actually two, since uucico wants "high-level" acknowledgements) for the uucico to talk to, or collecting the UUCP job files and blasting them across the line with something totally different. The second option (protocol driver hackery) would imply to simultaneously (a) get data from the local uucico and store it somewhere, (b) receive data from the remote side and store it somewhere else, (c) feed the data from (a) to the remote side, and (d) feed the incoming data to the local uucico once (a) is finished. The hard part is to decide what to do about line errors (you'll have to keep a massive amount of state) and what to do when the remote side says that it won't accept a file whose receipt you already acknowledged to the local uucico. As to sending files over with a different program -- I do have "sz" and "rz" here to do zmodem with if I have to, but they don't look like it would be particularly easy to convince them to run bidirectionally. Does anybody have something which can do real bidirectional stuff? < There is a protocol out there call Janus, I believe, that supports this. < Where? How? Documentation? Source code? -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/