Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!apple!ames!sun-barr!newstop!sun!datsun!shannon
From: shannon%datsun@Sun.COM (Bill Shannon)
Newsgroups: comp.dcom.modems
Subject: Re: MNP 5 vs. uucp 'g' (vs. Telebits)
Message-ID: <124413@sun.Eng.Sun.COM>
Date: 11 Sep 89 07:55:40 GMT
References: <124236@sun.Eng.Sun.COM> <1989Sep7.235838.11756@tmsoft.uucp>
Sender: news@sun.Eng.Sun.COM
Lines: 45

In article <1989Sep7.235838.11756@tmsoft.uucp>, mason@tmsoft.uucp (Dave Mason) writes:
> some of {f,t,e} protocols do error checking, but only on a
> 'whole-file' basis & reship the whole file if something went wrong.

't' and 'e' don't do any error checking at all.

> This is probably unlikely enough between the computer and the modem
> that file level checking is probably sufficient (if your silo
> overflows are frequent, I'd claim you had more problems than modem
> throughput).

oh, no doubt!  but just because I have these other problems I don't want
my files corrupted!  it's not throughput in the face of errors I'm
worried about, it's throughput in the normal case, while still being
able to detect and recover from errors.

Here's the problem.  Both 't' and 'e' send a "byte count" before
sending data, 't' before each block and 'e' before the whole file.  if
one byte of this byte count is dropped, the following bytes that are
really part of the file will look like part of the byte count.
similarly, in the case of 't', if bytes of the file are dropped the
following byte count could be "sucked into" the file.  this could
easily cause uucp to read more or less data than is actually in the
file.  as far as I can tell, if this happens, this can go undetected
and the file will be assumed to have been transferred successfully, but
an error will likely occur *after* the file transfer has completed.

> The bottom line?  From here, today, it's "get a Telebit" for 60-70%
> better throughput.  But I'm using this Microcom because the person at
> the other end of the phone line found the Telebits to be a crock, so I
> guess it just goes to show you...

Telebits are great, but they're expensive and likely to remain so.
V.32 modems are cheap, and are getting cheaper all the time.  Also,
V.32 modems work much better for interactive use, and for SLIP.
Telebits excel *only* for uucp transfers (ignoring the T2500 that
also does V.32; it's far too expensive).


maybe the answer is to build a uucp protocol that does error checking
*and* compression and ignore MNP?

is MNP just another case of a "smart" device doing a dumb thing?

	Bill