benderly@cs.columbia.edu (Dan Benderly) (02/15/89)
I am a graduate student who is doing a paper on the USENET/UUCP network. I am looking for a fairly brief though technical explanation of the protocols used in the UUCP program. I am also interested in the growth and development of the network, and in the routing algorithms that have been used. Please E-mail responses, and I will post a summary if requested. Thanks in advance, Dan benderly@cs.columbia.edu
phil@bcscal.UUCP (Phil Kemp) (02/16/89)
I have seen reference to various 'protocols' for uucp connections. Can anyone tell me what the different protocol designations are and what the associated attributes are... I am running an early release of HDB and want to connect to a Sun through a Multiplexor link to a DECserver and then connect through telnet from a VMS interactive session. How does one enforce the use of one or another protocol from both the initiation point or the connection point? This is sort of a follow-up to a previous article I posted regarding kermit and file transfers between my UNIX-PC and the remote SUN. I solved the file transfer problems by resetting some of the interactive session parameters on VMS. I now can get kermit, and zmodem working. UUCP will start using the standard 'g' protocol but fails due to flow control being used somewhere in the link... I have heard of the 'e' (error free) protocol. There was a posting referring to the 't' protocol for TCP/IP transfers recently. It would be nice to get an overview of the different protocols and how they can be implemented on the various versions of uucp. Thanks for any help... Either E-Mail or Re-post. Any helpful E-Mail I will summarize in a followup. Thanks.. -- Phil Kemp Boeing Computer Services, Calgary Voice - (403)-269-8281 phil@bcscal.uucp
yonatan@dybbuk.uucp (Jonathan Hanna) (05/08/89)
Does anyone have specs for the uucp e,f,t, or x protocols? -- Jonathan Hanna yonatan@dybbuk.uucp attcan!utzoo!yunexus!dybbuk!yonatan
jross@pilot.njin.net (Jeff Ross) (03/19/90)
I was wondering if anybody knows where I can get the specifications on the uucp protocols, g,x,f if they are available via ftp, or if somebody would be willing to mail them to me. thanks Jeff -- Just plain and simple.... arpa: jross@pilot.njin.net uucp: uunet!tronsbox!wisdom!jeff
john@cutler.uucp (John E. Babbitt Jr.) (04/20/91)
The only uucp protocol I'm familiar with is "g", but I've seen floating
around some mention of "e" and "f". What are they, and why are they still
in use? What other uucp protocols are there? What do most sites use?
My package can only communicate in "g" protocol, so does that means I won't
be able to link up with others that are "e", "f", or "xyzzy"? :-)
Regards,
John E. Babbitt, Jr. {UUCP: ...rutgers!ogicse!orstcs!cutler!john}
Senior Programmer/Analyst {Internet: cutler!john@cs.orst.edu}
Cutler & Company, Inc.
Medford, Oregon 97504
503/770-9014 (TDD only)bam@ncrnorw.Norway.NCR.NO (Asbjorn Muldbak) (04/21/91)
In article <1991Apr19.125453.22@cutler.uucp> john@cutler.uucp (John E. Babbitt Jr.) writes: >The only uucp protocol I'm familiar with is "g", but I've seen floating >around some mention of "e" and "f". What are they, and why are they still >in use? What other uucp protocols are there? What do most sites use? >My package can only communicate in "g" protocol, so does that means I won't >be able to link up with others that are "e", "f", or "xyzzy"? :-) > The 'g' protocol sends in packets of 64 bytes in size. Acknowledgement on packet basis. Quite slow, but very reliable. It assumes 8-bit datapath. The f protocol is designed for 7 bit ASCII data paths with control character restrictions. Binary files are converted to ASCII format before transmission and back on the other side. Checksum is done on a total file basis, so the entire file must be retransmitted if a noisy channel introduces an error. On reliable channels 'f' protocol gives a faster transfer rate. I use the 'f' protocol for all uucp/X.25 connections with hosts able to handle it, as it seems to be the fastest and most reliable on these connections. (More reliable is of course the g-protocol, but slower) I have had terrible results using 'e' on far away X.25 connections. (Europe <-> USA). Just silent death, until of the machines gave up on the connection. The 'e' protocol assumes a 8-bit datapath, that is completely reliable NO, repeat NO error checking is done. The 'e' protocol sends a character count for a file, before transmitting the actual file. Data is transmitted in 1024 byte blocks. High throughput, greatest risk of undetected file corruption. I use 'e' protocol for uucp/LAN connections. You should have no problem connecting to sites with these protocols, as (as far as I know at least) all support the g-protocol. If a site have set a default of f, uucp will just step back to using 'g', and data is flowing. I do not know of any other uucp-protocols, than e/f/g. Hope these comments answered your question Asbjorn Muldbak -- Bo Asbjorn Muldbak NCR Corporation, Norway. Fax. +47 2 953601 Dept: APS - Application and Project Support. email:Asbjorn.Muldbak@Norway.NCR.NO or [ncrcom,ncrdkcp,ncrsth,nuug]!ncrnorw!bam Opinions stated are my own, and does not represent NCR Corporation.
guy@auspex.auspex.com (Guy Harris) (04/23/91)
>I do not know of any other uucp-protocols, than e/f/g.
"t" - similar in concept to "e"; the "t" stands, as I remember, for
"TCP/IP" - Rick Adams invented it when at CCI, to make UUCP-over-TCP run
faster than it did when using the "g" protocol.
There are a couple of differences between it and "e"; as I remember,
they are that 1) they byte count is sent in network-byte-order binary,
rather than printable ASCII, and 2) some other difference that I don't
remember except that "t" does it a bit better than "e".
"x" - some kind of UUCP-on-X.25 implementation that AT&T had; I don't
know if they ever released it in source form, and I've heard it had lots
of problems.
"G" - I think this is a "g" variant that can handle bigger packets (the
problem with negotiating a bigger packet size in "g", as I remember, is
that some "g"-protocol implementations crash if you give them packets
that are too big; the idea of having a separate "G" is to avoid
negotiating a too-large packet size with an implementation that can't
cope).igb@fulcrum.bt.co.uk (Ian G Batten) (04/23/91)
In article <7322@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > "x" - some kind of UUCP-on-X.25 implementation that AT&T had; I don't > know if they ever released it in source form, and I've heard it had lots > of problems. It is indeed in the V.3 source distribution. It's useless in the UK, and I believe other places, because it marks the end of each transmission by sending a zero-length data segment. This is discarded by PSS in the UK. Therefore it works fine until the first C-CY exchange, at which point it hangs. There is also the ``d'' protocol, for use over datakit, in the V.3 sources. I've no idea what sort of protocol it is. ian
emanuele@overlf.UUCP (Mark A. Emanuele) (04/24/91)
In article <1407@ncrnorw.Norway.NCR.NO>, bam@ncrnorw.Norway.NCR.NO (Asbjorn Muldbak) writes: > > I do not know of any other uucp-protocols, than e/f/g. > I have source for HDB uucp that has d and x protocols d for datakit connections x for X.25 connections. Don't have the details handy, but could get them if you want them. - -- Mark A. Emanuele V.P. Engineering Overleaf, Inc. 218 Summit Ave Fords, NJ 08863 (908) 738-8486 emanuele@overlf.UUCP