garyb@abekrd.co.uk (Gary Bartlett) (03/22/91)
Can anyone tell me the range of data values sent by two communicating UUCICO processes. Is it a full 8-bit range (0-255), a full 7-bit range (0-127) or a selected range of characters (eg 32-126)? I am most interested in finding out whether it uses the ASCII values for DC1/3. Thanks, Gary --------------------------------------------------------------------------- Gary C. Bartlett NET: Gary.Bartlett@abekrd.co.uk Abekas Video Systems Ltd. UUCP: ...!uunet!mcsun!ukc!abekrd!Gary.Bartlett 12 Portman Rd, Reading, PHONE: +44 734 585421 Berkshire. RG3 1EA. FAX: +44 734 567904 United Kingdom. TELEX: 847579
gandrews@netcom.COM (Greg Andrews) (03/25/91)
In article <1991Mar22.102630.1057@abekrd.co.uk> garyb@abekrd.co.uk (Gary Bartlett) writes: >Can anyone tell me the range of data values sent by two communicating UUCICO >processes. Is it a full 8-bit range (0-255), a full 7-bit range (0-127) or >a selected range of characters (eg 32-126)? > >I am most interested in finding out whether it uses the ASCII values for DC1/3. > The 'g' protocol would pass an XOFF (DC3) as part of the packet header whenever it sends a negative acknowlegement (NAK) for packet number 3 (in the rotation of packet numbers from 0 to 7). It would send an XON (DC1) when sending a NAK for packet number 1. Almost as important, it would send an XOFF with the 8th bit set when sending a data packet numbered 2, and the last data packet the sender had received was numbered 3. It would send an XON as part of the header when sending a data packet numbered 2 when the last packet it had received was number 1. Every data packet is signalled by a control byte in the header that has its 8th bit set. Therefore, bytes above decimal 127 will appear in the data stream. Uucp 'g' does not 'escape' any characters that appear in the file data. If the file contains bytes corresponding to XON or XOFF, they will be passed as-is through the modems. If the file has been compressed, it's almost guaranteed to have bytes above decmal 127 and below decimal 32. In short, for the 'g' protocol, you need an 8-bit wide data path, and nothing between the sending computer and receiving computer must try to interpret any data bytes. If you're using high-speed modems, they must NOT be set to use XON/XOFF flow control. Any other devices in the data path must be completely transparent to data. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
jdeitch@jadpc.cts.com (Jim Deitch) (03/25/91)
In article <1991Mar22.102630.1057@abekrd.co.uk> garyb@abekrd.co.uk (Gary Bartlett) writes: >Can anyone tell me the range of data values sent by two communicating UUCICO >processes. Is it a full 8-bit range (0-255), a full 7-bit range (0-127) or >a selected range of characters (eg 32-126)? > >I am most interested in finding out whether it uses the ASCII values for DC1/3. > >Thanks, > >Gary >--------------------------------------------------------------------------- >Gary C. Bartlett NET: Gary.Bartlett@abekrd.co.uk >Abekas Video Systems Ltd. UUCP: ...!uunet!mcsun!ukc!abekrd!Gary.Bartlett >12 Portman Rd, Reading, PHONE: +44 734 585421 >Berkshire. RG3 1EA. FAX: +44 734 567904 >United Kingdom. TELEX: 847579 UUCP uses an 8 bit protocol. If it didn't how could you copy a binary and run it? Jim -- ARPANET: jadpc!jdeitch@nosc.mil INTERNET: jdeitch@jadpc.cts.com UUCP: nosc!jadpc!jdeitch
fenner@jazz.psu.edu (Bill Fenner) (03/25/91)
In article <1991Mar24.195246.11250@jadpc.cts.com> jdeitch@jadpc.cts.com (Jim Deitch) writes: |UUCP uses an 8 bit protocol. If it didn't how could you copy a binary |and run it? I dunno. How can you copy a binary using Kermit and run that? Kermit uses a 7 bit protocol (if you ask it to.) The UUCP g protocol requires an 8-bit datapath. There exist other UUCP protocols which do not require an 8-bit data path (i.e. the f protocol). -- Bill Fenner fenner@jazz.psu.edu ..psuvax1!hogbbs!wcfpc!wcf wcf@hogbbs.scol.pa.us (+1 814 238-9633 2400MNP5)
root@zswamp.fidonet.org (Geoffrey Welsh) (03/26/91)
Jim Deitch (jdeitch@jadpc.cts.com ) wrote: >UUCP uses an 8 bit protocol. If it didn't how could you >copy a binary and run it? PLEASE don't tell me that you can't imagine being able to transmit a binary, intact, over a 7-bit connection... it's done frequently, using what might be described as a variation of the technique we use to transmit binaries over the 1-bit connections we call serial ports! -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 The mile is traversed not by a single leap, but by a procession of coherent steps; those who insist on making the trip in a single element will be failing long after you and I have discovered new worlds. - me
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (03/26/91)
garyb@abekrd.co.uk (Gary Bartlett) writes: >Can anyone tell me the range of data values sent by two communicating UUCICO >processes. Is it a full 8-bit range (0-255), a full 7-bit range (0-127) or >a selected range of characters (eg 32-126)? The g and t protocols use all eight bits. Presumably e and x do so as well, although you shouldn't really use them ... >I am most interested in finding out whether it uses the ASCII values for DC1/3. The default (g) protocol does. This is a problem when running over X.25 through a PAD, thus was born the f protocol. Essentially it encodes non-printable characters into printable ones, and it explicitly wants XON/XOFF flow control. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6bbm.ab.can.noam The only thing open about OSF is their mouth. --Chuck Musciano
dgil@pa.reuter.COM (Dave Gillett) (03/26/91)
In <1991Mar22.102630.1057@abekrd.co.uk> garyb@abekrd.co.uk (Gary Bartlett) writes: >I am most interested in finding out whether it uses the ASCII values for DC1/3. Also commonly known as XOFF and XON....
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (03/27/91)
jdeitch@jadpc.cts.com (Jim Deitch) writes: >UUCP uses an 8 bit protocol. If it didn't how could you copy a binary >and run it? Maybe by encoding the 8 bits into 7? Kermit can be configured to use only printable ASCII characters and it has no problem shoveling eight bit data around either ... -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6bbm.ab.can.noam The only thing open about OSF is their mouth. --Chuck Musciano
woods@eci386.uucp (Greg A. Woods) (03/28/91)
In article <1991Mar22.102630.1057@abekrd.co.uk> garyb@abekrd.co.uk (Gary Bartlett) writes: > Can anyone tell me the range of data values sent by two communicating UUCICO > processes. Is it a full 8-bit range (0-255), a full 7-bit range (0-127) or > a selected range of characters (eg 32-126)? It depends upon which protocol is in use by uucico. There are several protocols, and some are 7-bit clean (eg. 'f'). > I am most interested in finding out whether it uses the ASCII values for DC1/3. I know for certain that 'f' protocol shouldn't but 'g' protocol can. -- 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
det@hawkmoon.MN.ORG (Derek E. Terveer) (03/29/91)
fenner@jazz.psu.edu (Bill Fenner) writes: >The UUCP g protocol requires an 8-bit datapath. There exist other UUCP >protocols which do not require an 8-bit data path (i.e. the f protocol). Huh? I thought that the f protocol merely assumed an error-free connection and said nothing about reducing the number of bit per byte, i.e., it is still 8-bit. derek -- Derek "Tigger" Terveer det@hawkmoon.MN.ORG -- U of MN Women's Lax I am the way and the truth and the light, I know all the answers; don't need your advice. -- "I am the way and the truth and the light" -- The Legendary Pink Dots
jdeitch@jadpc.cts.com (Jim Deitch) (04/01/91)
In article <1991Mar29.072005.7867@hawkmoon.MN.ORG> det@hawkmoon.MN.ORG (Derek E. Terveer) writes: >fenner@jazz.psu.edu (Bill Fenner) writes: > >>The UUCP g protocol requires an 8-bit datapath. There exist other UUCP >>protocols which do not require an 8-bit data path (i.e. the f protocol). > >Huh? I thought that the f protocol merely assumed an error-free connection >and said nothing about reducing the number of bit per byte, i.e., it is >still 8-bit. > >derek Here is the lines from fio.c : /* $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. * * When using this protocol with an X.25 PAD: * Although this protocol uses no control chars except CR, * control chars NULL and ^P are used before this protocol * is started; since ^P is the default char for accessing * PAD X.28 command mode, be sure to disable that access * (PAD par 1). Also make sure both flow control pars * (5 and 12) are set. The CR used in this proto is meant * to trigger packet transmission, hence par 3 should be * set to 2; a good value for the Idle Timer (par 4) is 10. * All other pars should be set to 0. * Normally a calling site will take care of setting the * local PAD pars via an X.28 command and those of the remote * PAD via an X.29 command, unless the remote site has a * special channel assigned for this protocol with the proper * par settings. * * Author: Piet Beertema, CWI, Amsterdam, Sep 1984 */ ....A bunch of lines deleted.... /* 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 */ ...A bunch more deleted..... So as you can see everything BEFORE 040 and after 171 is "quoted" by a special character. The reason the characters below 32 are changed is because some X.25 pads will think they are control codes for it and act on them, instead of just realizing they are a part of the data stream. The reason >171 is modified is because generaly X.25 is a 7 bit even parity environment. Jim -- ARPANET: jadpc!jdeitch@nosc.mil INTERNET: jdeitch@jadpc.cts.com UUCP: nosc!jadpc!jdeitch
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (04/06/91)
det@hawkmoon.MN.ORG (Derek E. Terveer) writes: >Huh? I thought that the f protocol merely assumed an error-free connection >and said nothing about reducing the number of bit per byte, i.e., it is >still 8-bit. Then you thought wrong. f is designed to work through PAD's, which don't usually have the capability of being fully eight bit transparent. So, the datga gets translated into a printable ASCII character if it isn't one already. Read the source ... -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6bbm.ab.can.noam The only thing open about OSF is their mouth. --Chuck Musciano