SY.FDC@CU20B.CC.COLUMBIA.EDU (Frank da Cruz) (09/06/85)
Info-Kermit Digest Thu, 5 Sep 1985 Volume 3 : Number 15
Departments:
SLIDING WINDOWS -
Sliding Windows Work on Fast Line with Slow Disk
Re: ANY-duplex Windows (2 messages)
MS-DOS KERMIT -
POPDOS2 and Kermit Problem
Problem with MS kermit on DEC Rainbow 100+
Leading Edge & Corona Portable -- Kermit Fit?
Kermit for the Hyperion?
IBM MAINFRAME KERMIT -
Solution to TSO Kermit vs 7171 Problem
Kermit with Yale ASCII?
----------------------------------------------------------------------
Date: Thu 22 Aug 85 15:42:46-EDT
From: John Mulligan <OC.SOURCE@CU20B.ARPA>
Subject: Sliding Windows Work on Fast Line with Slow Disk
Frank - I tried the windowing direct connect at 9600 baud with a standard
IBM PC (Floppies) and had no problems.
------------------------------
Date: Thu 22 Aug 85 15:46:43-EDT
From: John Mulligan <OC.SOURCE@CU20B.ARPA>
Subject: Re: ANY-duplex Windows
Dear Ken,
I would like to thank you for your messages on the windowing proposal.
They were well thought out and written, and helped us a great deal in
refining the proposal. I have been meaning to reply before, but I was
still learning the mail system on Columbia. Frank was the only one I
knew how to send messages to!
Anyway, we have been thinking about the half-duplex situation. I'm
sending our current thoughts to you before we go public with them.
First, the Send-Init packet. Define an additional bit in the capabilities
mask indicating half-duplex windowing:
Bit 1 2 3 4 5
reserved ATTRIB FULL HALF
Do a bitwise "AND" of the sender pair with the receiver pair.
Full Half
0 0 Kermit Classic
1 0 Full-duplex as defined now
0 1 Half-duplex extension to be elaborated
1 1 Either full or half *
*If both, default to half; shouldn't happen because
second send-init should pick one.
Second, half-duplex itself:
Create a new data packet type that says "this data packet is not the
last in this group; don't answer yet". Thus the current standard
DATA packet can be answered right away, and our current full-duplex
definition is consistent.
I'm suggesting the new packet type be called the WATA packet, and it
would be just like a DATA packet except that it would mean
"WAiT A minute, I'm not done sending this group, don't reply yet".
A DATA packet (as in "DAT's All for this group, go ahead and reply")
would signal the end of a particular group of packets.
The above definition is consistent with both classic KERMIT and with
the full-duplex windowing.
As the receiver processed WATA packets, it would compose the ACKs and
NAKs in the same manner as for full-duplex windowing, but buffer
them for sending when the half-duplex line was turned around (indicated by
receipt of a DATA packet).
This system should use almost identical code for both full and half
duplex windowing, and would (as you mentioned) make it very
easy to debug in half-duplex and then move to full-duplex.
Error handling, window rotation, etc. appear to remain the same,
at least at first glance.
We think the maximum half-duplex window size could be 63, instead
of 32, but we aren't totally sure.
Thanks again for your very helpful thoughts. Let me know what you think of
the above.
-John Mulligan
------------------------------
Date: Mon, 26 Aug 85 23:19:52 pdt
From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa
Subject: ANY-Duplex Windows
Glad to hear from you, John!
Here are my thoughts:
Repeated for the benfit of others:
>
> First, the Send-Init packet. Define an additional bit in the capabilities
> mask indicating half-duplex windowing:
>
> Bit 1 2 3 4 5
> reserved ATTRIB FULL HALF
>
>
> Do a bitwise "AND" of the sender pair with the receiver pair.
>
> Full Half
> 0 0 Kermit Classic
> 1 0 Full-duplex as defined now
> 0 1 Half-duplex extension to be elaborated
> 1 1 Either full or half *
> *If both, default to half; shouldn't happen because
> second send-init should pick one.
Yes, but I think that "1 1" should default to full duplex.
Both sides are capable, so why not use full-duplex?
(If you want to choose half-duplex with a pair of Kermits
capable of either, "SET WINDOW HALF-DUPLEX" or some such command
should cause only the half-duplex bit to be sent.)
Both sides should also send a super-packet size (S) in the
next byte following the window-size (W) byte.
If half-duplex windows are selected, then the super-packet size
used is the lower of the two super-packet sizes.
Super-packet size must be less than or equal to half the window size
(S <= W/2) :
1) We must have window size (W) >= 2x super-packet size (S) in case
the first packet of a super-packet is lost (then the next super packet
contains packet 1 plus packets S+1 through 2S-1).
2) We can only make use of W > 2*S in the case of multple retries
for a particular packet. (This could be useful in very noisy
environments...)
The normal case (the program default) should probably be for S = W/2.
Note that S may be more limited by a machine's input buffer size
than by W (=~ memory size). It might be less than W/2 even for full
duplex machines (i.e., how *long* can a full-duplex machine sustain
a full speed input without any pauses?).
Note that super-packet size is a maximum only.
More repeated stuff:
>
>
> Second, half-duplex itself:
>
> Create a new data packet type that says "this data packet is not the
> last in this group; don't answer yet". Thus the current standard
> DATA packet can be answered right away, and our current full-duplex
> definition is consistent.
>
> I'm suggesting the new packet type be called the WATA packet, and it
> would be just like a DATA packet except that it would mean
> "WAiT A minute, I'm not done sending this group, don't reply yet".
>
> A DATA packet (as in "DAT's All for this group, go ahead and reply")
> would signal the end of a particular group of packets.
>
> The above definition is consistent with both classic KERMIT and with
> the full-duplex windowing.
>
> As the receiver processed WATA packets, it would compose the ACKs and
> NAKs in the same manner as for full-duplex windowing, but buffer
> them for sending when the half-duplex line was turned around (indicated by
> receipt of a DATA packet).
I'm not convinced that we gain by adding a new packet type.
Note that we cannot send an EOL character to the half-duplex host
between packets, because this causes the host to finish the read
and probably miss the start of the next packet. On my system,
at least, the system not only can't send while it's receiving,
but, after completing a read, it doesn't buffer until a new
read is issued for the line.
System call overhead ensures that the next read will not be issued
until well after several characters of the next packet have gone
by, even if no processing is done on the packet in the meantime.
(The alternative is XON handshaking between packets, which
will defeat the whole pupose of super-packets.
Note also, that we have not gotten away from XON handshaking
between super-packets.)
This means that when the kermit program on a half-duplex host
gets the packet, an EOL has been received. EOL is a de-facto
super-packet delimiter.
As soon as the end of the super-packet (the EOL) is processed,
the program knows it can proceed to reply.
If one side is full-duplex, it can queue up ACKs and NAKs as it reads
packets, but it must wait for the EOL (and probably XON) before
sending them. I suppose that for a full-duplex host,
WATA/DATA is a way of providing the higher-level protocol
with the end of super-packet data which the half-duplex host
gets implicity by the nature of its i/o system.
It seems to me that making the send-packet routine wait for
receiving routine to get an XON is sufficent, although this
hides the super-packets from the packet-level protocol.
Is there a reason to tell it?
If so, perhaps the full-duplex kermit can implement a WATA
packet internally: a DATA packet received without an EOL gets
reported internally as a WATA,
but only DATA packets are actually sent over the wires.
I'm not real strong on this one way or the other;
I'm just wary of adding packet types.
As Bruce Cowan points out, a half-duplex receiver can NAK
bad-checksum packets since it *knows* which packets were supposed
to be sent (including which ones resent).
I'm not sure whether this helps or not, since the absence of an ACK
is just as sure an indication to the sender. *Something* (at least one
ACK/NAK) does have to be sent, however, to let the sender know
to retransmit.
The best policy is probably to send only ACK's unless no good packets
are received, in which case a NAK for the lowest-numbered outstanding
packet may be sent.
This has the advantage of agreeing with the full-duplex case,
for best commonality of coding.
It seems to me that where super-packets are most vulnerable is if
the EOL (or the XON) is lost. In that case, my system, at least,
will time out and throw away the whole super-packet!
Some simple kluges will help here: send some padding followed by a
second EOL character *after* each super packet if the padding
parameter is non-zero.
As long as we don't get into a situation where the end of the super-packet
(and the EOL) is lost on every transmission, though, we still gain:
the critical EOL characters are a lower percentage of the
total characters sent.
> This system should use almost identical code for both full and half
> duplex windowing, and would (as you mentioned) make it very
> easy to debug in half-duplex and then move to full-duplex.
>
> Error handling, window rotation, etc. appear to remain the same,
> at least at first glance.
I believe so, too.
> We think the maximum half-duplex window size could be 63, instead
> of 32, but we aren't totally sure.
I'm not sure that the gain would be worth making it different
from the full-duplex case. Ease of coding and all...
One thing I have not thought about yet is how to integrate long packets
with windows. Bruce makes a good case for allowing packets to be
close to 128 or 256 characters to take advantage of public data network
packet sizes. I lean towards using the published long-packet
extension rather than his proposed special case for up to triple-size
packets, though.
It seems that the easy solution is to state that window and super-packet
negotiations are really for windows of 94*W *characters*;
when using longer packets, you must scale W and S down accordingly.
This is not as flexible as one might wish for, though.
Your turn!
Ken Poulton
Bit by bit, byte by byte, we'll figure it out...
------------------------------
Date: Tue 13 Aug 85 13:45:37-EDT
From: Fuat C. Baran <BARAN@COLUMBIA-20.ARPA>
Subject: POPDOS2 and Kermit Problem
I have been testing some of the popups (Bellsoft) recently and I have
found one problem. The problem occurs when I use Kermit (v2.28) and
popdos2. Here is what happens:
I install the popup and go into kermit. Until I use popdos2 (calling
it up with ALT-U) I have no problems. Then I call popdos2 and do the
following: I cd to a subdirectory and a dir *.* of the subdirectory.
I then exit from popdos2 and continue with Kermit. I try transferring
more files but later when I look at the files I see that they are all
filled with garbage. The garbage looks like random characters and,
here and there, file names of the subdirectory that I had done the dir
on. I tried this several times and with different files and got the
same results. Kermit works fine until I do the cd and dir sequence in
popdos2. Any files transferred after that point come out as garbage.
So far that is the only major problem I have encountered with popups.
I minor irritation is the alarm clock feature in continuous display
mode. Every time the screen scrolls up a line it moves the clock (I
keep the display in the top right hand corner of the screen) up with
it and then it redisplays it where it should be. (If you put the
clock in some other place, on the bottom for example, then it scrolls
up with the page and you get multiple displays on your screen.)
Note: I have an IBM-PC with 256K and two disk drives. I use a TAXAN
monochrome display with a Paradise Color Card (yuk! [The Paradise
card has been giving me problems like substituting characters on my
screen ("S." -> "S*" with the "*" flickering, etc...)])
--Fuat Baran
BARAN@Columbia-20.ARPA
------------------------------
Date: Fri, 23 Aug 85 10:38:21 mdt
From: rgt%a@LANL.ARPA (Richard Thomsen)
Subject: Problem with MS kermit on DEC Rainbow 100+
I have (am currently) using MSKERMIT on my Rainbow 100+, connecting to a
Berkley 4.2 UNIX system on a VAX. When I run the Rand Editor under Kermit,
the cursor arrow keys do not work. When I run the Rand Editor using the
Rainbow built-in terminal emulator, then the arrow keys work. I suspect
that the Kermit program does not change the normal cursor keys to the
application cursor keys, but it does so with the keypad keys, which work
as expected.
I have not had a chance to look extensively at the code, but I guess I could
if that is desired.
Richard Thomsen
rgt@lanl.arpa
[Ed. - In a pinch, you can always make a file that does "set key" commands
for the cursor keys, and "take" the file whenever you want to run the
editor.]
------------------------------
Date: 25 Aug 1985 0040-PDT
From: Rob-Kling <Kling%UCI-20B@UCI-ICSA>
Subject: Leading Edge & Corona Portable -- Kermit Fit?
For reasons explained below, the new Leading Edge D machine
might be an attractive PC compatable. As might also a Corona portable
at about $1250.
Has anybody had experience using recent MS-Kermits (2.27 or 2.28) with
either of these machines. [I would also appreciate any comments on the
compatability or ruggedness of these machines if anybody has relevant
experience.]
Some dealers in Southern California are pricing the Leading Edge D Machine
rather aggresively -- with 640K, parallel & seriel port, Hercules-like board,
hefty power supply, monitor & 2 DSDD drives ... about $1300-$1400.
About $700 more for a 20MB Seagate or Rodine hard disk w/WD controller.
They will also take off about 25% for universities...... making the
floppy machine about $1150 and the hard disk machine about $1700.
These are attractive prices..... if the machine works well, is
about as compatable as anything else on the market, etc. (And if Leading
Edge doesn't go under in its endless suits with Mitsubishi.)
BTW. The machine has a small footprint and also comes with a 1 year warranty.
Processor is an 8088 at 4.77 MHz. No speed demon, but the aim seems to
be to aim at the highest cmpatability possible (Phoenix BIOS, ...).
I would apprecaite any comments on the compatability, ruggedness of the Leading
Eedge D machine from people who can share some recent experience.
I am told that this machine is just coming to market and that it is better (?)
than the earlier M machine which Mitsubishi manufactured for Leading Edge.
I'll summarize key responses for the net.
Rob Kling
Department of Information and Computer Science
University of California, Irvine
kling@uci-ics-a
PS. Corona has also recently dropped prices. I would also appreciate
comments on the IBM compatability & general value of the Corona portables
manufactured in the last year (since the ROM BIOS was changed because of the
suit by IBM).
------------------------------
Date: Wed, 4 Sep 85 11:48:05 pdt
From: Peter Ludemann <ludemann%ubc.csnet@csnet-relay.arpa>
Subject: Kermit for the Hyperion?
Does there exist a version of Kermit for the Hyperion
(also sometimes known as Bytec Hyperion or Anderson-Jacobson
Ajile) running DOS2.11 (DOS1.x is acceptable)?
The generic MS-DOS Kermit gets a "write error while reading from
COM1" error - I suspect the problem is that the Hyperion uses
a Zilog SIO chip instead of whatever the IBM-PC uses.
Thanks in advance,
Peter Ludemann
ludemann@ubc-cs.uucp (ubc-vision!ubc-cs!ludemann)
ludemann@cs.ubc.cdn (ludemann@cs.ubc.cdn@ubc.mailnet)
ludemann@ubc.csnet (ludemann%ubc.csnet@CSNET-RELAY.ARPA)
[Ed. - Generic MS-DOS Kermit should be able to work on any DOS machine.
It uses only DOS calls for i/o, and has no knowledge of any chip. Try
fooling with the SET PORT command, and maybe you'll stumble upon a device
designator that will work.]
------------------------------
Date: Wed 14 Aug 85 08:52:52-PDT
From: Wing Lee <WingLee%ECLD@ECLA>
Subject: Solution to TSO Kermit vs 7171 Problem
Good News! The problem we had with the Series/1 version of TSO-KERMIT
has been solved. The problem we were having was that TSO-KERMIT would
hang at random places whenever you tried to upload to TSO. One of
our Systems Programmers, Valaine Saito, discovered what we think
the problem is. What follows is Valaine's message to me.
> i looked at the kermit through the 7171 problem again since it appears
>that it really HAS to work if we're going to lose a s/1. i stumbled through
>the assembler program, it looks like the logic is okay. after determining
>that, i went to the s/1 and 7171 manuals to see what the difference was. it
>turns out that there is NO logical difference, but there clearly is a
>functional difference.
>
> both the s/1 and the 7171 have 64 char type ahead buffers. the s/1 must
>handle it differently. when i have both the host and micro kermits sending
>packet lengths of 60 (less than the 64 char buffer size), everything works
>fine. when either of the kermits sends > 64 packet lengths, the familiar
>"failure to receive ackn from host" msg appears on the micro and the transfer
>stops. (all this pertains to file transfer from micro to host, i assume the
>other way works since no one has said otherwise.) at 9600 baud, i ran a
>largish file (60+ kb) through a number of times (10 or so) and it worked
>every time with BOTH kermits sending packet sizes of less than 64.
>
> so the solution is to send packets of size X, where x is less than 64
>(i always tried sizes of < 64, i didn't try 64). the practical options
>are:
>
> tell users about the packet length problem and have them set both
> lengths themselves.
>
> re-code the host kermit to accept a max packet size of 63 or 64.
> (this isn't too cool because only the receive section has the
> problem. changing the max packet size would affect all
> sections.)
>
> re-code the host kermit to utilize the RPSIZ variable correctly
> and change the value to F'64' (or 63). RPSIZ is the max receive
> packet size.
I have tried sending packet sizes of 64 bytes and that works. When I tried 65
byte packets, the upload failed, so it looks like 64 is the magic number.
wing lee
[Ed. - For CMS Kermit, we will look into the possibility that the program
can determine if it's a 7171 (it's not clear that it reports itself
differently from a Series/1) and in that case use the smaller packet size.]
------------------------------
Date: Wed, 28 Aug 85 17:12 EST
From: Jim Ennis <JIM%UCF1VM.BITNET@WISCVM.ARPA>
Subject: Kermit with Yale ASCII?
What is the oldest version of the YALE ASCII communication package that
can be used with Kermit for upload download (i.e. transparency)?
We have an old turkey implementation using Yale ASCII V2.0 running
under EDX V3.2..... It is my understanding that I need to go to a
more recent version of the Yale ASCII support in order to utilize the
transparency capabilities of that later version. Furthermore, I need
to go to a more recent version of EDX before I can go to the more
recent version of the Yale package. Information on this subject will
be greatly appreciated...... The only reason this is an issue is be-
cause we have only floppies on the box (no hard drive) and I want to
get it right the first try. Sincerely.
[Ed. - We run version 2.0 of the Yale ASCII package, and version 3.2 at
update level P0A of the EDX Supervisor, and have experienced no problems.
There was, however, a complaint from Larry Bierma@NPRDC in the last Info-Kermit
digest, who claimed that file transfers through the Series/1 would "hang up"
even though they worked fine through the 7171 or 3704.]
------------------------------
End of Info-Kermit Digest
*************************
-------