Xref: utzoo sci.electronics:3084 sci.astro:2213 comp.dcom.modems:1965 comp.misc:2573 rec.ham-radio:5061
Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!killer!bigtex!james
From: james@bigtex.uucp (James Van Artsdalen)
Newsgroups: sci.electronics,sci.astro,comp.dcom.modems,comp.misc,rec.ham-radio
Subject: Re: N.B.S. Time Service
Keywords: Time Ticks
Message-ID: <2691@bigtex.uucp>
Date: 11 Jun 88 12:35:48 GMT
References: <455@trane.UUCP> <4691@watcgl.waterloo.edu> <585@otto.COM> <1255@neoucom.UUCP> <11983@ut-sally.UUCP> <5785@chinet.UUCP>
Reply-To: james@bigtex.UUCP (James Van Artsdalen)
Organization: F.B.N. Software, Austin TX
Lines: 36

IN article <5785@chinet.UUCP>, les@chinet.UUCP (Leslie Mikesell) wrote:
> Is there a file transfer protocol that works well over satellite?  Zmodem
> is supposed to allow the amount of outstanding data to be specified, but
> the sources that have been posted do not include a dialer or login routine
> to establish a connection.

The posted sources are for the transfer protocol, nothing more.  It's expected
that you'll use "cu" or equivalent to make the underlying connection.  In DOS
you could use Pro-YAM or any of a number of modem programs that support
external protocol modules (Qmodem and Procomm?).  When you're writing a
protocol driver, adding the connection code just yields a mess of a program
(witness the various Kermit implementations).

> Does anyone have something like this working?
> How about uucp 'x' protocol (or 'f' or 'g' with the # of packets increased)
> or a kermit w/sliding windows for unix?  Is there any real-world data on
> transfer rates using any of these protocols?

I don't think C-Kermit supports sliding windows.  uucp 'g' only permits
a maximum of 7 packets or just under 500 bytes outstanding (about 2.2 seconds
at 2400bps).  Every now and again Chuck Forsberg posts real numbers for all
this stuff.

The best bet is Zmodem.  The source code is readily available and in C.  The
code is small enough to work with too.  It's pretty CPU efficient on both
ends, and can allow for indefinite delays in propagation (it isn't necessary
to have ACKs streaming back at the sender).  Zmodem also handles varying
line quality by dynamicly adjusting the packet size from a low of 32 bytes
to at least 1K per packet.  Finally, the most important thing to me is that
on those occasions when you need to transfer GNU emacs by modem, you don't
have to worry about the line being dropped two hours into your international
phone call: you just call back and have zmodem continue the transfer where
it left off.  To the best of my knowledge, none of the other protocols you
list can continue a transfer in the middle of a file like this.
-- 
James R. Van Artsdalen   ...!ut-sally!utastro!bigtex!james   "Live Free or Die"
Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746