info-kermit@ucbvax.ARPA (03/08/85)
From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA.ARPA>
Info-Kermit Digest Thu, 7 Mar 1985 Volume 2 : Number 10
Departments:
ANNOUNCEMENTS -
Old Files Moved
UNIX KERMIT -
C-Kermit Modules for Regulus
Unix Shell Script for ftp'ing Kermit Programs, Cont'd
Bug in C-Kermit
C-Kermit 4.2 Problems
MISCELLANY -
TSX+ Kermit-11 Clarification
MS-Kermit and TopView
Series-1 Support in IBM Mainframe Kermit
Resonating Packets, Satellite Delays to India
----------------------------------------------------------------------
Date: 7 Mar 1985 1853-EST
From: Frank da Cruz <SY.FDC@CU20B>
To: Info-Kermit
Subject: Old Files Moved
Since the Kermit distribution area on CU20B has grown sufficiently large
that it will no longer fit on a single reel of tape in ANSI D format at
1600 bpi, several old versions of Kermit have been moved to KE:, the
Kermit-Extra area. These are:
KER:PC*.* - Version 1.20 of IBM PC Kermit. Replaced by KER:MS*.*.
KER:CPM*.* - Version 3.9A of CP/M-80 Kermit. Replaced by KER:CP4*.*.
KER:UX*.* - Version 3.0 of Unix Kermit. Replaced by KER:UX*.*.
The old files are still accessible, but now they're in KE: instead of KER:.
------------------------------
Date: 1 Mar 1985 0953-EST
From: Joe Smiley, Du Pont Co.
Via: LCG.KERMIT@DEC-MARLBORO.ARPA
To: Info-Kermit
Subject: C-Kermit Modules for Regulus
I have transferred two source files for C-Kermit ckzreg.c and ckxreg.c
for using C-Kermit under the Regulus (Version 4.2) operating system.
These were created from the Berkeley versions and have been tested
(although not extensively). The modifications were minimal.
[Ed. - These changes arrived too late to be included in C-Kermit 4.2, and
would have been hard to add in any case, given the reorganization that the
program has suffered in the meantime. I hope Joe can add the Regulus
support to the new release and send these modules to us again. Meanwhile,
if anybody needs them, they're available for anonymous FTP from
KE:CK%REG.* -- note, KE:, not KER:.]
------------------------------
Date: Tue, 5 Mar 85 14:58:27 est
From: randy@nlm-vax (Rand Huntzinger)
To: Info-Kermit
Subject: Unix Shell Script for ftp'ing Kermit Programs, Cont'd
The following patch, applied to the 4.2 BSD ftp program, will allow mget
to work in TENEX mode, as required by my shell script to retrieve Kermit
versions from Columbia. It isn't a particularly elegant solution, but
it's functional.
[Ed. - The shell script (announced in V1 #8), along with the ftp patch
(which is too long to include here) are in KT:UXFTP.* on CU20B (The
Kermit-Tools area).]
------------------------------
Date: Wed, 6 Mar 85 19:13:15 cst
From: Rusty Haddock <haddock%waltz%ti-csl.csnet@csnet-relay.arpa>
To: sy.fdc@CU20B.ARPA
Subject: Bug in C-Kermit
Problem:
With C-Kermit (on Ultrix/BSD4.2) in server mode talking to
MS-Kermit on a TI Professional a "REMOTE DIR" command from the TIPC
will be displayed without carriage returns - just line feeds.
All of the REMOTE commands act this way.
Cause:
What appears to be the cause is that the C-Kermit command
"SET FILE TYPE BINARY" affects ALL output from the UNIX system.
whether it's file transfer or REMOTE command. Unfortunately,
you must terminate the SERVER, do a "CONNECT", and then
"SET FILE TYPE TEXT" to have the server output the CRLF pair for
the REMOTE commands.
Fix:
Sorry, I have none (yet) as I'm not that familiar with
the C-Kermit source code but it may very well be easy to fix.
I would think that all that would need to be done is to have the
BINARY TRANSFER flag (or some such indicator) unset when transmitting
REMOTE command output and restored upon completion.
Your time and consideration would be appreciated. Thanks, Rusty
ARPA: Haddock%Waltz%TI-CSL.csnet@CSNet-Relay.arpa
Rusty@Maryland
CSNet: Haddock@TI-CSL
USENET: {ut-sally, convex!smu, texsun, rice} ! waltz ! haddock
[Ed. - Diagnosis correct. This problem will be fixed in the next release.]
------------------------------
Date: 7-Mar-85 12:29:17-MST
From: wester@FORD-COS1.ARPA
To: Info-Kermit@CU20B.ARPA
Subject: C-Kermit 4.2 Problems
I have just compiled the new ckermit on my 11/70 running Sys V. There is
one problem in ckdebu.h. The typedef unsigned long LONG caused a compile
error "misplaced long". Changing this to 'typedef long LONG' resulted in
a clean compile. I have not completly tested, but a preliminary test seems
to work o.k.
While trying to compile it on my VAX running 4.1bsd I also encountered an
error. In ckxunx.c there is a line '#include <sys/time.h>' and references
to two structures 'timevalue and timezone' that are expected to be in this
include file. I do not have that include file although I do have a <time.h>
and a <sys/times.h> neither one has either of the two referenced structures.
I don't have time at the moment to work on tracing the problem further.
Keep up the good work. Kermit is the best "free" software I have seen in
many years.
Gene Wester
[Ed. - Thanks! I haven't heard complaints about the typedef from other
Sys III/V places. But that's what the typedefs in ckdebu.h are for --
change 'em to fit what your compiler can do.
This is the first I've heard about the time stuff on 4.1; sys/time.h is
used for a couple things -- getting the current date/time string (e.g. for
time stamps in the various logs) and for operation of the millisecond
timer in the function msleep. If anyone can supply these functions for
4.1, please send them in! Especially if there's a way to do it that works
in both 4.1 and 4.2.]
------------------------------
DATE: THURSDAY, 07 MAR 1985
FROM: BRIAN AT UOFT02
TO: SY.FDC AT CU20B
SUBJECT: TSX+ Kermit-11 Clarification
To clarify a point, there is NO such thing as K11TSX.HEX or K11TSX.SAV.
TSX+ users need to use K11XM or K11RT4, the first uses virtual overlays
the later does not. The RT version of Kermit-11 ALWAYS determines at run
time if it is on RT11, PRO/RT11 or TSX+ and loads the appropiate overlay
for terminal i/o correspondingly.
brian nelson
brian@uoft02.bitnet
------------------------------
Date: Thu Feb 28 1985 21:19:09
From: Marco Papa <papa%usc-cse.csnet@csnet-relay.arpa>
To: info-kermit@CU20B
Subject: MS-Kermit and TopView
What are the recommended values of the parameters for MS-Kermit's PIF
(Program Information File) to work under TopView?
Marco
USC Computer Science Dept.
UUCP: ...!sdcrdcf!uscvax!papa
CSNET: papa@usc-cse.csnet
ARPA: papa%usc-cse@csnet-relay.arpa
[Ed. - We fooled with it a little bit, but then lost our TopView disk.
Here's the best we can remember:
Program size 100K
Does map screen
Can't run in background
Doesn't use 8087
Usurps all interrupts
It's really a little smaller than 100K, and it really doesn't usurp ALL
the interrupts. It would be nice if it could run in the background while
transferring files, but since it fields interrupts from the port, you
can't do it. And it can't run inside a window during connect mode because
it writes directly to screen memory (at least if you have H19 terminal
emulation "on"). If anybody wants to try this out and send back exact
instructions on how to install Kermit-MS under TopView, we'll include them
with the distribution.]
------------------------------
Date: Thu, 07 Mar 85 09:32:37 PST
From: KARL@USCVM (Karl P. Geiger)
To: (many people)
Subject: Series-1 Support in IBM Mainframe Kermit
[Ed. - This messages summarizes answers to a query broadcast over much of
BITnet.]
Greetings GentleBeings:
Thank you all for your answers to my letter. I received many "I can
help" and "Please help me!" replies.
Briefly, UMDB people sent me a KERMIT module, VIC@QUCDN claims to have
a running KERMIT written in Pascal, SPGGTS@UCBCMSA has a running version
he is willing to send along, and NJG@CORNELLA has sent me some code
plus mods to CMS in UPDATE format. Finally, Daphne Tzoar at Columbia
(DFT@CUVMA) sends word that she is incorporating all the interesting
mods for S/1 or 7171 support into Kermit and intends to release the
new version in three to four weeks.
Yale people have asked "Why aren't you using YTERM? We wrote it to
support just what you want." My answer, and reason for annoying
so many people on the net, is Yes, we are running YTERM in our IBM
PCs, but we have DEC-20s, VAX/VMSs, Unixes (Unices?), and PR1ME
Rabbits all which must talk to DEC Rainbows, PRO 350's, and CP/M
machines. I use YTERM in my PC and PCTRANS to up/down load files
to VM frequently, but I would like a more general tool to gain
access to other systems. Kermit has become the standard by consensus.
Personally, I intend to wait for Daphne to complete her work and
release the new Kermit. I thank everyone else for their assistance,
contributions, and hard work to get Kermit running at their sites.
It makes more sense to me to use the 'standard' code which springs
from the fountainhead, however.
I will distribute the code I have received from UMDB and CORNELLA
to those who want it.
Thank you all again...
:Karl
------------------------------
Date: 6 Mar 1985 1820-EST
From: Joe Smith (JMS@C930.Tymnet)
To: Frank da Cruz
Via: LCG.KERMIT@DEC-MARLBORO
Subject: Resonating Packets, Satellite Delays to India
I too have noticed this problem, where KERMIT sends each packed twice. I
have seen it between KERMITs that do clear the input buffer. It is not a
deficiency in a particular implementation of KERMIT, but instead is a
problem in the KERMIT protocol.
The current operation, that of resending the entire packet when there is a
timeout in getting an ACK, works only if the original packet got lost. It
fails when the packet gets to the other end intact and was merely delayed
in transit.
What I have observed is the following:
KERMIT-20 sends packet of data (call this 1A)
KERMIT-PC sends an ACK, but it is delayed in the network
KERMIT-20 times out, and sends a duplicate of the original (packet 1B)
KERMIT-20 sees the delayed ACK 1A, sends packet 2A
KERMIT-PC gets duplicate packet 1B, sends ACK 1B
At this point, the delay in the network is not present. Therefore KERMIT-20
gets ACK 1B immediately after sending packet 2A. Since this is not what it
was expecting, KERMIT-20 resends the data as packet 2B. KERMIT-PC may be
confused as to why KERMIT-20 keeps sending every data packet twice, but it
stores the right data on disk and ACKs both packets. For every other packet
that KERMIT-20 sends, it gets an ACK for packet "N-1" when expecting the
ACK for packet "N", and sends a duplicate packet "N".
The KERMIT protocol needs to be revised. Whenever an ACK for packet "N-1"
is received, it should be thrown away, the SEND TIMEOUT value be increased
if possible, and KERMIT should resume waiting for ACK "N".
This would allow the two KERMITs to get back in sync.
I would like to make a suggestion for the KERMIT II protocol. Only send
duplicate packets when an explicit NAK has been received. Send a different
type of packet for timeout or user hitting the RETURN key. This packet must
be distinct from all other packets, and come in at least 5 flavors.
1) HELLO, ARE YOU RECEIVING, THE LAST DATA PACKET I SENT WAS #123
2) YES, I AM RECEIVING, THE LAST DATA PACKET I GOT WAS #122
3) HELLO, ARE YOU STILL SENDING, THE LAST DATA PACKET I GOT WAS #456
4) YES, I AM SENDING, THE LAST DATA PACKET I SENT WAS #457
5) HI, I AM AS SERVER WAITING FOR YOUR COMMAND
With this mechanism, KERMIT would not have to blindly clear the input buffer.
[Ed. - Your diagnosis is correct. But rather than wait for Kermit II, it
would be sufficient to employ the heuristic "discard redundant ACKs" which
you suggest, and which was also suggested in the BYTE article. This is
not really a protocol issue; it's more like an implementation decision,
and can be added to any Kermit program. The worst that can happen is that
the second ACK will not arrive within the timeout interval (which you are
free to adjust on a per-packet basis), causing retransmission of the last
data packet, which is what happens now. Maybe this trick will show up
in the next release of C-Kermit.]
------------------------------
End of Info-Kermit Digest
*************************
-------