LDSHANER@MTUS5.BITNET (Leon D. Shaner) (03/12/91)
I have reason to want my UUCP to call through a certain 7-bit connection... Is this likely to be more trouble than it is worth??? I wasn't sure if UUCP required 8-bits or not... I've managed to get my expect/send prompts finely tuned to the new connection, but it times out one expect/send past password... (Debug says it got something it was looking for, but then it just sits there...) Can anyone tell me anything I might try??? -Leon ---------------------------------------------------------------------- | Leon D. Shaner - EE Undergrad / Amiga Bitswap Central Dispatch / | <LDSHANER@MTUS5.BITNET> / (906)482-8248 - DLG PRO! BETA / | <abcd!leon@balance.cs.mtu.edu>/ FREE! :24 HOURS :80 MB :2 LINES!/ ------------------------------------------------------------------
src@scuzzy.in-berlin.de (Heiko Blume) (03/18/91)
LDSHANER@MTUS5.BITNET (Leon D. Shaner) writes: >I have reason to want my UUCP to call through a certain 7-bit connection... >Is this likely to be more trouble than it is worth??? no, no problem. >I wasn't sure if UUCP required 8-bits or not... I've managed to get my >expect/send prompts finely tuned to the new connection, but it times out >one expect/send past password... (Debug says it got something it was >looking for, but then it just sits there...) >Can anyone tell me anything I might try??? you must use f protocol to do this. in fact i receive a full news feed with it. of course news (and other 8bit data) should be 7 bit encoded before transmission. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public UNIX source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
woods@eci386.uucp (Greg A. Woods) (03/22/91)
In article <1991Mar17.224601.27427@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: > you must use f protocol to do this. in fact i receive a full news > feed with it. of course news (and other 8bit data) should be 7 bit > encoded before transmission. The last time I looked at the UUCP 'f' protocol code (which was just seconds ago), it explicitly quotes the 8'th bit using the following conversions: /* Byte conversion: * * from pre to * 000-037 172 100-137 * 040-171 040-171 * 172-177 173 072-077 * 200-237 174 100-137 * 240-371 175 040-171 * 372-377 176 072-077 */ I.e. 'f' actually lets you transmit 8-bit data through a 7-bit only link with UUCP. I.e. 'f' is 8-bit transparent. I've used 'f' several times over x.25 links (for which it was designed to do). Thankfully some vendors have included 'f' in their UUCP's, since even with the file from which the following opening comment was taken, binary only sites are stuck. /* $Header: fio.c,v 1.20 85/04/30 12:57:32 rick Exp $ */ /* %M% %I% %E% (Mathematisch Centrum) */ /* * flow control protocol. * * This protocol relies on flow control of the data stream. * It is meant for working over links that can (almost) be * guaranteed to be errorfree, specifically X.25/PAD links. * A sumcheck is carried out over a whole file only. If a * transport fails the receiver can request retransmission(s). * This protocol uses a 7-bit datapath only, so it can be * used on links that are not 8-bit transparent. * [... how to set up an X.25 PAD with X.28/X.29 ...] * * Author: Piet Beertema, CWI, Amsterdam, Sep 1984 */ On the other hand, AT&T's 'e' protocol may work over 7-bit paths, if the data has the 8'th bit quoted. I don't know if the rest of the protocol is 8-bit transparent though. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
david@bacchus.esa.oz.au (David Burren [Athos]) (03/25/91)
In <1991Mar22.001432.1420@eci386.uucp> woods@eci386.uucp (Greg A. Woods) writes: >In article <1991Mar17.224601.27427@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >> you must use f protocol to do this. in fact i receive a full news >> feed with it. of course news (and other 8bit data) should be 7 bit >> encoded before transmission. >The last time I looked at the UUCP 'f' protocol code (which was just >seconds ago), it explicitly quotes the 8'th bit using the following >conversions: >/* Byte conversion: > * > * from pre to > * 000-037 172 100-137 > * 040-171 040-171 > * 172-177 173 072-077 > * 200-237 174 100-137 > * 240-371 175 040-171 > * 372-377 176 072-077 > */ >I.e. 'f' actually lets you transmit 8-bit data through a 7-bit only >link with UUCP. I.e. 'f' is 8-bit transparent. Ah yes, but sending 8-bit data over it will blow up the transmissions by causing multiple characters to be sent. If you get your news batcher to compress to 7-bit data then the only characters that need to be quoted are those from 000-037 and 172-177. I would have thought this would give you much better throughput on the line. Didn't someone (in Germany?) do a 'k' protocol in their PC UUCP that sent data over 7-bit links? _____________________________________________________________________________ David Burren [Athos] Email: david@bacchus.esa.oz.au Software Development Engineer Phone: +61 3 819 4554 Expert Solutions Australia, Hawthorn, VIC Fax: +61 3 819 5580 [speaking for myself of course]
csg@pyramid.pyramid.com (Carl S. Gutekunst) (03/26/91)
In article <1991Mar22.001432.1420@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: >On the other hand, AT&T's 'e' protocol may work over 7-bit paths, if >the data has the 8'th bit quoted. I don't know if the rest of the >protocol is 8-bit transparent though. Neither the 't' nor 'e' protocols will work over what one would normally con- sider a "7-bit path," like a PAD. 't' binary encodes its header, and 'e' has a NULL terminated ASCII string in its header. Of course, the real problem with 't' and 'e' is that neither does an error checking. They're strictly for use over error-free transport protocols, like TCP/IP or an OSI stack. (Can you see it? uucico 'e' protocol over OSI Session over TP4 over SNDCF over X.25.) On the 'f' protocol, note that for really random binary data -- like compress output -- you are better off prefiltering the data through an encoder like btoa or the Netnews encode program. The 'f' 8-bit quoting can add 50% to the size of the data, while atob adds a fixed 18%, and ~news/encode 11% or so. But if speed and/or transmission cost are not that important, then 'f' will handle 8-bit data just fine. <csg>