Path: utzoo!attcan!uunet!decwrl!apple!voder!pyramid!csg
From: csg@able (Carl S. Gutekunst)
Newsgroups: comp.protocols.iso
Subject: Re: UUCP over X.25
Message-ID: <128268@pyramid.pyramid.com>
Date: 25 Sep 90 22:11:37 GMT
Sender: daemon@pyramid.pyramid.com
Reply-To: csg@able.pyramid.com (Carl S. Gutekunst)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 19

In article <1791@hulda.erbe.se> prc@erbe.se (Robert Claeson) writes:
>>if your x.25 line is 8 bit transparent (the pad should allow to set this)
>>you might also (apart from f) look into e protocol which is a streaming
>>protocol that expects the line to be error free -> no overhead at all.

Bad, bad. There is no error checking in 'e' at all. It shouldn't be used
on anything that doesn't give you end-to-end error correction. X.25 is
"mostly" error free. Your link over HST modems is probably getting lots
of errors that you never know about. (You just get bad data.)

>Actually, as I understand it, the 'e' protocol isn't intended to be
>used via a PAD, but directly over X.25 PLP (layer 3) and with the X.25
>interface directly in the system.

'e' was *intended* for use with TCP/IP over Ethernet. In SVR3.2, it can
be used over any Streams/TLI interface, although Ethernet was still the
only thing implemented by AT&T at that time.

<csg>