james@bigtex.uucp (James Van Artsdalen) (08/31/88)
In article <10500001@osiris.cso.uiuc.edu>, hamilton@osiris.cso.uiuc.edu wrote: > what would it hurt to negotiate a huge *max* packet size (say, 1024+), Probably won't work. Most uucps seem to crash when you negotiate anything other than 64. > since you can always send smaller packets. every packet carries a size > field; if the code is written correctly, packets only as large as needed > will be sent. i modified my uupc to do this, but when my uucp neighbor > sent me 256-byte "HY" messages, i took it out again. I don't know what the design goal was, but my assumption was that when the remote system sent me its desired window and packet size, that's what it wanted, and nothing else. It can't tell what window size I'm really using of course, but I wouldn't shocked if sending smaller packet sizes crashed the remote. It would be better to add a new protocol to solve these problems, something with a real CRC instead of a simple checksum and much lower overhead (preferably streaming). Also worth the effort is that ability to continue aborted transfers (this involves changing the transaction protocol, not the packet protocol). -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
hamilton@osiris.cso.uiuc.edu (09/01/88)
james@bigtex says: > ... > > > what would it hurt to negotiate a huge *max* packet size (say, 1024+), > Probably won't work. Most uucps seem to crash when you negotiate anything > other than 64. as i recall, i was replying to a suggestion that packet sizes greater than 256 bytes were undesirable. it was assumed that the uucico's involved were to be "fixed". i've tested at least one BSD-derivative(?) uucico that does handle larger packets (pyramid OSx). > > since you can always send smaller packets... > > I don't know what the design goal was, but my assumption was that when > the remote system sent me its desired window and packet size, that's > what it wanted, and nothing else. It can't tell what window size I'm > really using of course, but I wouldn't shocked if sending smaller > packet sizes crashed the remote. why would a remote "desire" a packet larger than necessary? i get it, let's go back to source code blank-padded to 80 cols/line :-) i think it makes more sense that the negotiation is to set maximums. surely if one side has enough buffer space for 1024-byte packets, 64-byte ones should not cause heartburn. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,seismo,pur-ee,uunet}!uiucuxc!osiris!hamilton ARPA: hamilton@osiris.cso.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%osiris@uiuc.csnet Phone: (217)333-8703
les@chinet.UUCP (Leslie Mikesell) (09/02/88)
Has anyone tried using the "e" protocol that is built into the AT&T SysVr3.x uucp for use over networks over a trailblazer or other error-correcting modem? Results? Also, the attmail machine offers protocols "d" and "v". Does anyone know what these are (and why the rest of use don't have them)? Les Mikesell
rkh@mtune.ATT.COM (Robert Halloran) (09/02/88)
In article <6452@chinet.UUCP> les@chinet.UUCP (Leslie Mikesell) writes: >Has anyone tried using the "e" protocol that is built into the >AT&T SysVr3.x uucp for use over networks over a trailblazer or >other error-correcting modem? Results? If your machine has trouble keeping up with a steady data stream, using 'e' might be a problem; uucico basically sends a packet with the final file size then does write()'s. The modems may deliver a clean line but if the receiver's port drops bytes you'll never know it until it's too late. >Also, the attmail machine offers protocols "d" and "v". Does >anyone know what these are (and why the rest of use don't have them)? 'd' protocol is for use over the Datakit network; useful chiefly within AT&T. I'm unfamiliar with any 'v' protocol. >Les Mikesell Bob Halloran ========================================================================= UUCP: att!mtune!rkh Internet: rkh@mtune.ATT.COM Disclaimer: If you think AT&T would have ME as a spokesman, you're crazed. Quote: "History is made at night. Character is what you are in the Dark." - Dr. Lizardo/John Whorfin, "Buckaroo Banzai"
dave@arnold.UUCP (Dave Arnold) (09/06/88)
(Robert Halloran) writes: > In article <6452@chinet.UUCP> les@chinet.UUCP (Leslie Mikesell) writes: > 'd' protocol is for use over the Datakit network; useful chiefly within > AT&T. I'm unfamiliar with any 'v' protocol. I really doubt the 'd' protocol has goals much different than 'x' or 'e' or 't'. Seems like all these could have been combined into one. One prococol for an error-free channel. Or am I missing somehting? -- Dave Arnold dave@arnold.UUCP {cci632|uunet}!ccicpg!arnold!dave
les@chinet.UUCP (Leslie Mikesell) (09/07/88)
In article <169@arnold.UUCP> dave@arnold.UUCP (Dave Arnold) writes: >I really doubt the 'd' protocol has goals much different than 'x' or >'e' or 't'. Seems like all these could have been combined into one. >One prococol for an error-free channel. Or am I missing somehting? E protocol does no flow control or error checking of its own which makes it reasonable only over network connections where end-to-end error checking is already done. Even with trailblazers there is the link between the serial port and the modem, and the problem of flow control. The need for different protocols follows the transmission channel requirements (i.e. is it 8-bit transparent, does it have a turn-around delay, is flow control required..). Then the protocol needs to be tuned for frame size and the window of unacked data (keeping in mind the question of "How much data are you willing to throw a something that may be trying to interpret it as dialing commands or operating system commands or..."). Since the uucico convention is to select a protocol by a letter code with no parameters, the different protocols are required. Les Mikesell
smb@ulysses.homer.nj.att.com (Steven Bellovin) (09/07/88)
In article <169@arnold.UUCP>, dave@arnold.UUCP (Dave Arnold) writes: > > I really doubt the 'd' protocol has goals much different than 'x' or > 'e' or 't'. Seems like all these could have been combined into one. > One prococol for an error-free channel. Or am I missing somehting? Some of the protocols we're talking about were tuned to particular hardware environments. The 'd' protocol relies on the ability of the Datakit(r) VCS to propogate 0-length writes, which TCP cannot do. Not only that, the 0-length write is accompanied by a special control byte, which some versions of dio require on input. Dio also issues some ioctl calls to the driver so that reads return on end-of-block, not just when the user's buffer is full. (This could be done differently today with HDB.) All of these considerations led Peter and I to invent eio. (Incidentally, eio was originally written for UNET, 3Com's TCP/IP, and antedates 4.2bsd.) Tio was developed later, and independently; there doesn't seem to be much need for both it and eio. I've never heard of vio; xio was for a (rather specialized) X.25 interface available. And I've heard rumors of a protocol that worked via shared disks; the sender merely informed the receiver of the name of the file to be sent. Does anyone know any more about that? --Steve Bellovin
honey@umix.cc.umich.edu (Peter Honeyman) (09/07/88)
Steven Bellovin writes: >All of these considerations led Peter and me to invent >eio. (Incidentally, eio was originally written for UNET, 3Com's >TCP/IP, and antedates 4.2bsd.) Tio was developed later, and >independently; there doesn't seem to be much need for both it and eio. my recollection is that you did the work, and i took the credit. that being the case, did i ever tell you about the horrible bug in the 'e' protocol? i now use 't' whenever i do tcp/uucp. peter
rick@seismo.CSS.GOV (Rick Adams) (09/07/88)
> eio. (Incidentally, eio was originally written for UNET, 3Com's > TCP/IP, and antedates 4.2bsd.) Tio was developed later, and > independently; there doesn't seem to be much need for both it and eio. I "invented" tio. It was first done for UNET, 3Com's TCP/IP, then ported to 4.1C BSD, then 4.2BSD. I've often wondered which was done first. They were certainly done independently (great minds....). I'd guess somewhere in March-June, 1983 for tio. Both protocols do the same thing. They first sent the number of bytes in the file, then blast the file out the line. They differ in how they encode the number of bytes. At the time, I was mucking with the networking internals, so I chose to use the "network byte order" [i.e. htonl()], while eio uses an ascii string terminated by either a null byte or a new line (I forget which). I'm sure that if they knew I had hacked up tio they wouldn't have invented eio. Similarly, had I know about eio, I wouldn't have bothered with tio. ---rick
mikej@cpmain.UUCP (Michael R. Johnston) (09/07/88)
In article <7272@bigtex.uucp> james@bigtex.UUCP (James Van Artsdalen) writes: >It would be better to add a new protocol to solve these problems, >something with a real CRC instead of a simple checksum and much lower >overhead (preferably streaming). Also worth the effort is that >ability to continue aborted transfers (this involves changing the >transaction protocol, not the packet protocol). Might it be a good idea to use the zmodem protocol and merge it into UUCICO? The sources are readily available and it could probably be hacked fairly easily to fit within the confines of the uucp world. -- Michael R. Johnston - @NET: mikej@cpmain.uucp ...{cmcl2!phri!,uunet!}dasys1!cpmain!mikej || ...philabs!mergvax!cpmain!mikej
honey@umix.cc.umich.edu (Peter Honeyman) (09/08/88)
according to the archives of uucp (a complete collection of sccs files), eio was incorporated into honey danber on 30 june 1983. so it looks like rick won by a nose. some mail from steve, and a close examination of s.eio.c reveals that my earlier note was somewhat inaccurate. i wrote eio.c (damn it!), cribbing heavily from xio.c. steve improved it in feb 84, and i fixed it again in 86. wish i had known rick back in 83. peter
james@bigtex.uucp (James Van Artsdalen) (09/08/88)
In article <10500003@osiris.cso.uiuc.edu>, hamilton@osiris.cso.uiuc.edu wrote: > james@bigtex says: > > I don't know what the design goal was, but my assumption was that when > > the remote system sent me its desired window and packet size, that's > > what it wanted, and nothing else. > why would a remote "desire" a packet larger than necessary? I have no idea. It doesn't matter. If I don't use the packet size the remote requests, the remote may crash (many seem to do so). Since a crashed uucico has a throughput of exactly 0, whereas whatever it asked for may do better, I do whatever it asks for. > i think it makes more sense that the negotiation is to set maximums. > surely if one side has enough buffer space for 1024-byte packets, > 64-byte ones should not cause heartburn. You have no idea what's going on in that other uucico. For all you know, there's a comparison to make sure that all incoming packets have the "right" size. I just don't see the benefit in not doing whatever it asks for. It would be nice to extend 'g'. It would be better not to break existing ancient implementations. Very few people have the luxury of source to fix bugs. -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746