Xref: utzoo comp.dcom.modems:4049 comp.mail.uucp:3324
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!decwrl!sdsu!usc!apple!oliveb!pyramid!csg
From: csg@pyramid.pyramid.com (Carl S. Gutekunst)
Newsgroups: comp.dcom.modems,comp.mail.uucp
Subject: Re: UUCP over X25 [Was Re: Telebits and uucp g-protocol]
Keywords: Telebit Trailblazers, g-protocol, uucp
Message-ID: <75292@pyramid.pyramid.com>
Date: 28 Jun 89 07:30:30 GMT
References: <335@nixtor.UUCP> <10391@smoke.BRL.MIL> <1989Jun12.185746.7217@eci386.uucp> <193@cat.Fulcrum.BT.CO.UK> <1989Jun22.154318.25599@eci386.uucp> <203@cat.Fulcrum.BT.CO.UK>
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 25

Couple of notes regarding UUCP over X.25.

The biggest problem with 'g' protocol for many users isn't the delays (which
can be terrible), it's the cost. 'g' protocol typically triples the packet
charges on networks like PSS and Telenet that make you pay by the segment.

The delays are much more noticable on international links, e.g. between the 
U.S. and Germany. You can reduce the delays considerably by increasing the
X.25 packet window size, oddly enough. Also note that 'g' requires 8-bit
transparency, which may not be possible on some PADs, requires funny PAD
parameters in any event, and (so Telenet tells me) isn't always guaranteed
on some international gateways.

You should never never never use 'e' or 't' protocols over X.25. These are
raw 8-bit interfaces that do no error checking. Anything goes wrong, and
you'll never know about it. Even the simple 8-bit checksum of 'f' is a big
improvement. Also, 'e' and 't' have no provision for inband flow control,
e.g. XON/XOFF. 'f' allows this. Important only if you are using a PAD.

The 'x' protocol is completely useless. It requires a zero-length packet
passed end-to-end to mark end-of-file. This is impossible on a PAD, illegal
on some networks, and dropped for "efficiency" reasons by some vendor's raw
X.25 interfaces.

<csg>