Tom Dunigan <dunigan@ornl-msr.ARPA> (11/16/84)
Question: Should uucp be able to function over a flow-controlled network that uses XON/XOFF as flow control. It appears that the uucp conversation hangs for large messages over our DCA stat mux network. If there is a way to make uucp work, I would like to know it. If the packet-size negotiation could be inhibited from increasing the packet size that might help. KERMIT seems to work just fine over the same network. thanks.
henry@utzoo.UUCP (Henry Spencer) (11/18/84)
> Question: Should uucp be able to function over a flow-controlled > network that uses XON/XOFF as flow control. It appears > that the uucp conversation hangs for large messages > over our DCA stat mux network. If there is a way > to make uucp work, I would like to know it. If the > packet-size negotiation could be inhibited from increasing > the packet size that might help. KERMIT seems to > work just fine over the same network. Uucp's normal protocol (the "g" protocol) absolutely must have a 100% transparent 8-bit data path. I.e., XON/XOFF is out. There is no easy way around this. Even if you tune your connection so flow control never ever gets invoked, you'll still be in trouble because uucp uses binary headers in its packets and will probably produce something that looks like an XON or XOFF sooner or later. Kermit was designed to work through mainframe tty drivers, which are much crankier than networks; no surprise that it copes well. Alas, uucp is a different story. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
lee@kcl-cs.UUCP (Lee McLoughlin) (11/18/84)
In article <5805@brl-tgr.ARPA> Tom Dunigan <dunigan@ornl-msr.ARPA> writes: >Question: Should uucp be able to function over a flow-controlled > network that uses XON/XOFF as flow control. It appears > that the uucp conversation hangs for large messages > over our DCA stat mux network. If there is a way > to make uucp work, I would like to know it. If the > packet-size negotiation could be inhibited from increasing > the packet size that might help. KERMIT seems to > work just fine over the same network. >thanks. Uucp normally won't be able to function over a network that doesn't provide a full 8-bit transfer mode. Occasionally its going to generate characters like ^S/^Q in its headers and if the network is going to gobble them up its not going to work. If you have source then you might add in a new protocol. Uucp allows for more that the default 'g'-protocol so you could add one that avoids this problem. In the UK many sites use a modified uucp that gives you the choice between using a variant on the standard 'g'-protocol and the 'f'-protocol. The former converts all messages into text on sending and back to binary again on arriving so that Unix and networks can do what they like with control chars for flow control. If you have very clean lines then you might care to use the 'f'-protocol. It does something similar, except it presumes that you never corrupt characters and that TANDEM mode is enough to prevent losing stuff. -- UKUUCP SUPPORT Lee McLoughlin <UK>!ukc!lmcl kcl-cs!lee "What you once thought was only a nightmare is now a reality!"
dmmartindale@watcgl.UUCP (Dave Martindale) (11/20/84)
> Question: Should uucp be able to function over a flow-controlled > network that uses XON/XOFF as flow control. As others have pointed out, if your network can handle moderate-length bursts of data without losing it, uucp's own windowing scheme will work. But sometimes, you HAVE to have flow control between the CPU and the network - an example is Sytek Localnet, which is arbitrarily slow depending on how congested the network is right now. One simple fix (well, kludge) is to add a simple byte-stuffing layer underneath the packet driver, which takes any XONs, XOFFs, and other objectionable characters (some I/O packages won't transmit NUL, for example) and encode them as a unique sequence of two characters before transmission, performing the reverse transformation at the other end. This allows the use of flow control, and slows things down only a little since only a few bytes get expanded. More CPU overhead, though.
hamilton@uiucuxc.UUCP (11/22/84)
> Question: Should uucp be able to function over a flow-controlled > network that uses XON/XOFF as flow control. >>One simple fix (well, kludge) is to add a simple byte-stuffing layer >>underneath the packet driver, which takes any XONs, XOFFs, and other >>objectionable characters (some I/O packages won't transmit NUL, for >>example) and encode them as a unique sequence of two characters >>before transmission, performing the reverse transformation at the other >>end. This allows the use of flow control, and slows things down only a >>little since only a few bytes get expanded. More CPU overhead, though. i have a similar problem with multiplexors. even worse, mine eat the parity bit, so i only get a 7-bit channel. i have implemented the byte-stuffing kludge for my machines (turns out to be almost trivial). if you're interested, send me mail. if i get enough requests, i'll just post it to net.sources. wayne ({decvax,ucbvax}!pur-ee!uiucdcs!uiucuxc!)hamilton