Message-ID: <9094@brl-tgr.ARPA>
Date: Sat, 9-Mar-85 03:52:31 EST
Article-I.D.: brl-tgr.9094
Posted: Sat Mar  9 03:52:31 1985
Date-Received: Tue, 12-Mar-85 21:35:24 EST
Sender: news@brl-tgr.ARPA
Lines: 354

Info-Kermit Digest         Fri,  8 Mar 1985       Volume 2 : Number 11

Departments:

  UNIX KERMIT -
	C-Kermit 4.2 ready for UUCPing from okstate
	Oklahoma State UUCP Information
	C-Kermit vs Line Locking (2 messages)
	C-Kermit Remote Host Commands vs Binary Mode (2 messages)

  MISCELLANY -
	Resonating Kermit Packets

----------------------------------------------------------------------

Date: 7 Mar 85 23:40:01-CST (Thu)
From: Mark Vasoll 
To: Info-Kermit
Subject: C-Kermit 4.2 ready for UUCPing from okstate

	Well, pre-release version 4.2 of C-Kermit has arrived safely from
Columbia and is ready for UUCP downloading.  We are planning to post this
version to Usenet's "net.sources" newsgroup tomorrow (3/8/85).  We hope
to prevent another outbreak of postings by providing this *one* posting
while C-Kermit V4.2 is hot off the presses.  We will take all possible 
precautions to prevent some overzealous mailers (or News handlers) from getting
hungry.

	Please direct all questions and problem reports regarding this
message, the C-Kermit 4.2 posting, and the UUCP Kermit Distribution
service to the following address.  Your message will be routed to the
person maintaining the distribution at that time.  Mail sent to my
personal login will be answered, but could be delayed several days.

	Our UUCP line will now be available on a 24 hour basis.
Unfortunately, we still can offer only one line....  Of course we would
welcome donations of equipment.... :-)

UUCP Kermit Distribution Assistance:

UUCP:  {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!uucp-support
ARPA:  uucp-support%okstate.csnet@csnet-relay.arpa

Thanks,
Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University

------------------------------

Date: 8 Mar 85 10:00:00-EST
From: Frank da Cruz 
To: Info-Kermit
Subject: Oklahoma State UUCP Information

Here again is the information about UUCP access to the Kermit distribution
from Oklahoma State U:

UUCP access to the complete Kermit distribution is available from the
Department of Computing and Information Services, Oklahoma State University,
Stillwater, Oklahoma.

You need to set up "okstate" as a site in your "L.sys" UUCP dialing file
using the information listed below.  You can then issue the following 
command on your system:

	uucp okstate\!/u/kermit/ck\* /usr/spool/uucppublic

   (this example will retrieve the Unix version of Kermit)

I chose "/usr/spool/uucppublic" as the destination on your system since
the destination must be WIDE OPEN (drwxrwxrwx) to everyone.  You should
not remove files from your uucppublic until the entire transfer is complete
including any redials that are necessary.  If you do remove some files
our system may retransmit them, resulting in a higher phone bill for
you. 
 
There are 2 files available that contain information about the entire
distribution.  We recommend that you retrieve these files first.  They
are "00readme.txt" which explains the file name conventions used, and
"00directory" which is a complete listing (by name) of all files in the
distribution.  These files will enable you to choose the right files
the first time to save those high dollar phone bills.

-- UUCP Login information --

Site Name    :  okstate
Phone number :  (405) 624-6953  (one line only)
Login name   :  uucpker
Password     :  thefrog
Hours        :  24 hours per day, 7 days a week
Problem      :  okstate!uucp-support  (UUCP)
  reports    :  uucp-support%okstate@csnet-relay  (ARPA)

The phone number is for 300/1200 baud (bell compatible).

The following is a sample L.sys line (\r is a carriage return).
You might want to put a time restriction on Any. ("Any2100-900" in
Illinois)

okstate Any ACU 1200 405-624-6953 "" \r ogin: uucpker word: thefrog

Just a few notes on how to best retrieve parts of the Kermit distribution
using UUCP...

  -  Install the proper L.sys entry and test it using the debugging option
     of UUCICO (-x).  Repeat this step until you successfully complete a
     "no work" connection, this will verify that your L.sys entry is correct
     and will minimize frazzled nerves.

  -  Retrieve the files `00readme.txt' and `00directory' with the following
     commands:

          uucp -c -d okstate!/u/kermit/00readme.txt /usr/spool/uucppublic
          uucp -c -d okstate!/u/kermit/00directory /usr/spool/uucppublic

     You will have to escape the exclamation point if you are using the
     C shell (i.e. ...okstate\!/u/kermit...).

  -  Choose the versions of Kermit that you wish to transfer and issue the
     proper UUCP command.  Some systems don't seem to like wildcards, but
     in any case the wildcards will have to be escaped from your shell. The
     following command would retrieve the files relating to C-Kermit:

          uucp -c -d okstate!/u/kermit/ck\* /usr/spool/uucppublic

     PLEASE NOTE THE USE OF /usr/spool/uucppublic!  Unless you *really* 
     understand how UUCP's protections work you should not change this!  A
     number of people have queued >100 files and had their systems refuse
     to store them in out of the way places.  This results in wasted phone
     time!

  -  If you are having problems connecting to our system PLEASE send mail
     to {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!uucp-support

  -  Kind words also make my day!

Thanks,

Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University

UUCP:  {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!vasoll
ARPA:  vasoll%okstate.csnet@csnet-relay.arpa

[Ed. - This file is online at CU20B as KER:OKSTATE.TXT.]

------------------------------

Date: Fri, 8 Mar 85 01:23:45 est
From: Ken Yap  
To: sy.fdc@cu20b.arpa
Subject: C-Kermit vs Line Locking

I like the new C Kermit but I wonder if a couple things could be made
options instead of hardwired.

The scenario: we use "tip" to do our dialing out, we are not even
allowed to know the phone numbers. After reaching the other system and
starting up a remore Kermit there, we suspend "tip" with ~^Z, then
start up a local Kermit.

Unfortunately the new Kermit gets in the way by: (1) checking for the
absence of a lock file in /usr/spool/uucp and (2) requiring a "set
speed" after the "set line" command.

Could a new settable option called say, "pre-connected", be added to
circumvent these checks? I believe others might be in the same
situation.

Thanks for a good piece of software.

	Ken

------------------------------

Date: Fri 8 Mar 85 07:51:07-PST
From: Herm Fischer 
Subject: Re: C-Kermit vs Line Locking
To: SY.FDC@CU20B

I like the idea of having a "preconnected" test.  But that probably
is a site-level thing, rather than a end-user level thing.

I'd not like end-users able to set preconnected and then access lines in
an unlocked fashion.

So, I'd recommend some -D flag when compiling kermit for that, say
an augmentation to make which adds a "-DPRECONNECT" flag when it
is compiled.  

Of course, this is hip-shooting, and may need some tweaking to work...

  Herm

[Ed. - Before putting this line-locking code into C-Kermit, the Unix
experts (including Herm) involved had a lengthy discussion of whether and
how it should be done.  There are many issues, and many strong opinions;
the readership of Info-Kermit was mercifully spared.  The resulting code
is a compromise, which, as Ken points out, doesn't work at sites that do
not allow users direct access to the line or modem.  Since this
arrangement is likely to be site-wide, then Herm's suggestion is probably
the best way out.  Note that the goal of this line-locking feature is to
prevent two (or more) processes (like uucp, tip, or kermit) from using the
same line at the same time, for reasons of security and data integrity.
At the same time, it is important that the line-locking feature not deny
access to a line which is actually free.  There is a fine line separating
these two requirements, and strong opinions about which side to favor in
ambiguous situations.]

------------------------------

Date: Fri 8 Mar 85 13:28:31-EST
From: Jeff Damens 
Subject: C-Kermit Remote Host Commands vs Binary Mode
To: sy.fdc@CU20B.ARPA

In the last Kermit Digest, there was a suggestion that commands like
REMOTE HOST always do newline conversion instead of obeying the image
(set file type binary) flag.  This will make it impossible to use
kermit as a filter for binary files - for instance, one might wish to
pipe kermit output to a plot filter and issue the command "remote host
graph | spline | ..." to generate a graph on a mainframe and plot it
locally.

A more general solution to the problem would be to allow the remote
kermit to receive commands from the local kermit.  Then the user could
say something like "remote command set file type text" to change the
image setting without connecting back to the remote system and
restarting kermit.

[Ed. - This is the "remote kermit" command, which has been in the protocol
manual for a long time, but never implemented.  Maybe next release...
Meanwhile, the problem reported by Rusty Haddock in the last digest will
not be solved as easily as I thought.]

------------------------------

Date:     Fri, 8 Mar 85 14:22:25 GMT
From:     Cjk@ucl-cs.arpa
To:       info-kermit@cu20b.arpa
Subject:  Resonating Kermit Packets

     A few further points on pervasive packet duplication (or, for that
matter, triplication etc.), following on Joe Smith's analysis in
info-digest 10.

     This sort of problem (caused by network congestion, satellite delays
etc.) is quite well understood by mainframe networking buffs.  There are
other ways it can get going as well as the route set out by JMS.  Once
started, with a Kermit-type protocol (which always retransmits on
timeout), it is stable and will continue until there is a network error
(which fixes it, since the lost packet will be replaced by its duplicate).

     The most authentic way to avoid it (without changing the
packet-sequences) is to ensure that the sender, acknowledger and network
have timeout/delay periods related so that:

           (2 * Tnet) < Tsend < (Tack - 2 * Tnet)

for all expected values of Tnet.  Unfortunately this is going to result in
rather long delays when a send packet is lost unless Tnet is quite small
(which it isn't).

     What happens on the network concatenation I use regularly (one X25
and one LAN with a low-performance gateway) is that there is a
transmission delay in both directions, both ends time out, and there are
then two complete sets of packets circulating.  It so happens that I am
dialling in to the X25 @ 300baud, so reception is quite slow.  The modem
lights show that reception is actually continuous, the duplicate ack being
received while the next data packet is going out (the micro has
interrupt-driven read).

     A simple and effective recovery mechanism is to flush the input
buffer at the end of the block-transmit as well as at its beginning.  This
will destroy the head of the duplicate block, which is all that is needed.
With variable network delay, it doesn't always work at once, but will in
due course.  There is a risk that this algorithm will destroy a needed
block if the other end turns around very fast, so perhaps it's better as
an option than always on.  This way the timeouts do not need to be long,
so recovery from lost data still takes place quite quickly.  Note,
incidentally, that if the micro was doing a half-duplex transmit, it would
not see the incoming duplicate block; perhaps file transfer for micros
should always be arranged to be in a pseudo-half-duplex mode!

     What seems essential to me is that the micro-Kermit keep its user
informed of the arrival of duplicate blocks.  Then at least he/she can
either take evasive action or curse and start rewriting Kermit.

                                Chris Kennington.

------------------------------

Date: 8 Mar 85 12:37:00-EST
From: Frank da Cruz 
To: Info-Kermit
Subject: Re: Resonating Kermit Packets

Timeouts are a complicated issue.  You want the timeout interval short
enough to catch missing packets without inducing undue delays, but long
enough to avoid spurious timeouts.  In order to set the optimum timeout,
you must know the speed of the communication line (the baud rate), the
length of the packet being timed, the current network delay, the packet
processing time (assembly/disassembly, data fetch/store), the load on the
host, and maybe other factors as well.  The problem is that not all of
these quantities are knowable at a given time, and on some systems not at
all -- for instance some systems provide no function to tell you the baud
rate of a line.  Network delays can appear and disappear suddenly, so a
timeout adjusted on this basis will tend to be wrong at the endpoints of
such events.  A host which can monitor its load can adjust its own timeout
accordingly (as DEC-20 Kermit does), but the Kermit on the other end has
no way of knowing about this.  A micro may have a small constant packet
processing time for n K worth of packets, but when the next packet comes,
it must take time out to dump its buffer to disk (CP/M-80 Kermit).  Etc.

The packet input buffer can be cleared at various times:

1. At the beginning of a transaction:  Important for clearing out stacked
   up NAKs from an idle server.

2. Before reading a packet:  Obviously a poor idea.

3. After reading a packet:  Can't hurt.  It will tend to work beneficially 
   when the network delay or the remote system load is decreasing, and have
   no effect at other times.  Most Kermit programs do this, and it is
   often sufficient for getting resonating Kermits back in sync.

4. Before sending a packet:  Equivalent to the previous case, except that
   additional time has passed in processing the packet just received, so
   the likelihood of finding something in the buffer (like the beginning of
   an unwanted packet) is increased.

5. After sending a packet:  The likelihood of finding characters in the
   buffer is still higher, but so is the likelihood that they will be
   characters from the packet you're looking for.

The length of the switching delay between writing and reading is crucial.
If the delay is negligible, it won't hurt to clear the input buffer after
sending, providing the clear function can be executed quickly.  If the
delay is long, or unpredictable, then case 5 would be equivalent to case
2, and you'd never be able to read a packet.

C-Kermit is an excellent vehicle for experimentation with these
heuristics -- it's written in a high level language and runs on a variety
of systems from small PC's to large timesharing systems, and the next
release will most likely embody the results of our combined experience
(experiments and results welcome!).

------------------------------

End of Info-Kermit Digest
*************************
-------