info-kermit@ucbvax.ARPA (07/19/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Info-Kermit Digest Thu, 18 Jul 1985 Volume 3 : Number 5
Departments:
KERMIT PROTOCOL EXTENSIONS -
Kermit Extension Proposal Feedback
Re: Proposals
Checksum versus CRC
Kermit Extensions
Kermit Extended Packet Lengths Proposal
Kermit Protocol Enhancements
New vs Classic Kermit
MISCELLANY -
Re: IBM 3270/PC and Kermit
RSX Kermit Warning
Kermit for Mac L Running Unix
Terminal Emulator w/Kermit: Beta-test Site Query
MS-Kermit 2.26 and Hercules Graphik Card
----------------------------------------------------------------------
Date: Thu 18 Jul 85 19:09:55-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit Extension Proposal Feedback
The following messages are in response to the first Kermit extension
proposal, presented without comment. The second proposal (sliding windows,
an effort which is being coordinated by people at The SOURCE Telecomputing)
is not quite ready yet, but should appear shortly. If you sent a response
that doesn't appear below, send it again -- we lost our file system on CU20B
last night and some messages may have been lost.
------------------------------
Date: Tue, 16 Jul 85 02:12:32 pdt
From: Scott Weikart <cdp!scott@Glacier>
Subject: Re: Proposals
I would definitely like to have either sliding window protocol or long
buffers, but I'm not sure which one (or if I need both). We're working with
some other non-profits to setup long-distance telecommunications between UN*X
and MS-DOS machines, and would like to use kermit as our transport mechanism,
but we're worried about kermit efficiency with long round-trip times (eg
packet-switched networks) or long-distance high-speed modem connections. The
packet-networks should be error- corrected so that long packets would seem to
make sense, but I don't know if you'll get hing up by buffer sizes in the
network (the nets I'm thinking of are Uninet, and maybe Tymnet or Telenet).
We may also be using some of the new high-speed pseudo-full-duplex modems,
and I don't know enough about their error rates or buffer size factors
either; if it's error rate is high and and it doesn't do partition a block
and use its own sliding window protocol, it might be good to use half-duplex
lurching window with small packets.
I'm not so worried that many/most kermits won't be able to handle either
extension. For people like us who are interested in using kermit for the
transport mechanism of sophisticated telecommunications services, probably
only the more capable machines will be considered as part of the system
(although one may argue that an MS-DOS machine is not very capable).
As for user education about large packets, people could maybe implement an
adaptive mode that would try a 1/3 or 1/2 smaller packet each time a
transport media truncated a packet. But that's more hairiness.
------------------------------
Date: 15 Jul 1985 1941-EDT
From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO.ARPA>
Subject: Checksum versus CRC
I haven't seen a single clear review of the above - I STILL BELIEVE THAT
Checksumming of mostly analog based circuits is SUPERIOUR. CRC [ and all
quasi-mathematical "analysises" assume BIT-drops] is SUPERIOUR in catching
missing BITS [one typically can be "reconstructed" depending on the "polynom"
- two or [sometimes more] can be "detected". CHecksumming is good for
"detecting" single-bit changes [no chance to "reconstruct" - since the
position of the "change" is not known - and [obviously.. only a 50% chance to
"catch" double-bit errors].... HOWEVER - and here lays the "settle"
difference -- ANALOG CIRCUITS TEND NOT TO DROP BITS - THEY DROP MINIMALLY
WORDS and TYPICALLY "SENTENCES" -- AND CHECKSUMMING HAS A HIGH CHANCE TO
"catch" these DROPS or MODIFICATIONS - since typically [on ANALOG CIRCUITS]
FULL [either ON- or OFF-Bit sequences are substituted] -- this [by the way]
also explains my long-standing objection to CRC-protocol in MODEM
[acknowledged by the experience - that ON "BAD" lines switching from
CHECKSUMMED PROTOCOL to CRC-PROTOCOL DOESN't make a "bit of a difference". -
Yeah, I know; there's an even more serious flaw in MODEM- protocol - in that
ACK/NAK msgs are NOT encased into "message-protocol" and thereby on a "bad"
line MODEM looses typically in ACK/NAK traffic.]
Let me clarify [after re-reading] the above SUPERIOUR - it summs up the
"expended CPU-time {and number of program instructions}" - as compared to the
achieved results {I.e. probability to detect an ERROR}.
Rgds,
Bernie.
------------------------------
Date: Tue 16 Jul 85 21:07:07-EDT
From: Richard Garland <OC.GARLAND@CU20B.ARPA>
Subject: Kermit Extensions
I perked my ears up at one statement in your introduction to the extensions
you outlined: "Each packet must be ACKed" and you even gave an example of
a half duplex "lurching" window where a bunch of packets are sent and then
a bunch of ACKs are returned.
I would suggest two ideas for ACKs that DECnet uses:
o ACKing only the last good packet and
o piggyback ACKing.
In the first case if, packets 9, 10, 11, and 12 are sent successfully, the
receiver ACKs 12 and this *implies* 9, 10, and 11 were also good. If 9, and
10 were good and 11 was bad on the other hand, the receiver NACKs 11, and
this implies 11 is bad, but 9 and 10 were good. Then the sender resends
starting at 11. This scheme allows a lot less reverse traffic. Usually
there is a limit on the number of packets that will be sent before getting
some ACK but that is the sliding window protocol which you are working out
and I won't bother about that part of it. (DECnet uses about 3 versions of
it).
piggyback ACKing simply means that an ACK or a NAK can be combined with
another packet going in the right direction and is relavent for full duplex
data streams. Perhaps Kermit will never have full duplex data (as opposed
to packets) so this idea may be irrelavent. But if on the other hand you
want to send a bunch of packets, then send an END packet, a type of
piggybacking would allow the receiver to ACK the last n packets and the END
packet all at once.
By the way, I don't think sliding windows and large packet extension ideas
are mutually exclusive ways to improve performance.
------------------------------
Date: Tue, 16 Jul 85 20:24:42 PDT
From: Bruce_A._Cowan%SFU.Mailnet@MIT-MULTICS.ARPA
Subject: Kermit extended packet lengths proposal
Overall this looks pretty good, but I'd recommend a couple of small changes:
1. Change the extended length specification to be simply 12 bits transmitted
the same way as the 2-byte checksum. This limits the maximum packet size
to 4096 bytes, but that is plenty when the best checksum is CRC-CCITT.
It is also as big as any host's usual input buffer as far as I know.
2. Include the LEN byte in the header checksum so that both checksums start
at the same byte. Having the header one start 1 byte later than the packet
one doesn't make any sense and will confuse the implementator.
I believe that the last sentence of the second-to-last paragraph is missing a
"NOT". As it stands, it contradicts the first sentence of the same paragraph.
(That is the paragraph about the extended header not being prefix-encoded.)
Finally, I think there is a small bug in the advanced state table shown in
the 3 April 84 protocol manual (there may be a newer one but that is the
newest I have). The Send_Gen_Cmd state should allow for receiving an F packet
in the case that it was entered from the Send_Server_Init state and sent a R
command. That is because the server will, I expect, conclude that it doesn't
need to send a S(0) because of receiving and Acking the I(0). (I haven't
tried this with a server to be sure, but the Rec_Server_Idle state
description sure implies to me that is how the server will work.)
------------------------------
Date: July 17, 1985, 09:15 CEST
FROM: <#D15%DDATHD21.BITNET@WISCVM.ARPA>
Subject: Kermit Protocol Enhancements
Hi,
I hope my questions are not too late for this stage of the
discussion.
1.) which kind of systems would be able to use the large
packets?
2.) which kind of systems can afford (pgm size, complexity)
the necessary changes to the software?
3.) how does the proposal fit the rules of the early days
of Kermit development (to have a simple, cheap to implement
protocol for connecting especially small systems)?
4.) where are the ends, or in other words, wouldn't it be better
to develop a new protocol with enhanced performance (e.g
larger packet, high speed lines, parallel activities on the
lines)?
Martin Knoblauch
TH-Darmstadt, D-6100 Darmstadt, West Germany
EARN/BITNET: #D15 at DDATHD21 (the number sign is really part of my UID)
------------------------------
Date: 17 JUL 85 09:34-EST
From: BRIAN%UOFT02.BITNET@WISCVM.ARPA
Subject: New vs Classic Kermit
The proposals for large packets (and likely sliding windows) are not going to
work out well on pdp-11's as the buffers in all the execs are fairly small,
ranging from a max of 36 for rsx, 255 for rsx11m+, 140 for rt, ??? for p/os,
and max of about 500 for rsts/e (depending on available small buffer pool).
Thus xon/xoff would come into play rather soon. Of course, xonxoff control
is no better (much worse,really) that send/ack for each packet.
------------------------------
Date: Mon, 15 Jul 85 12:42:33 edt
From: Paul Placeway <paul%ohio-state.csnet@csnet-relay.arpa>
Subject: Re: IBM 3270/PC and Kermit
We have been running kermit for IBM PCs and clones for 6 months on our 3270
PC with no problems whatsoever. We run a 9600 baud line between the 3270 PC
and our Vax to do file transfers (9600 is very nice, but the Unix version is
too slow (no, we havn't gotten the latest version of Unix kermit)). I have
one suggestion, however: get a normal PC keyboard for your 3270 PC. The
position of ESC, Control, and some other keys is a PAIN.
Paul Placeway
OSU CIS Dept. Lab
...!cbosgd!osu-eddie!paul
paul@ohio-state (CSNet)
------------------------------
Date: 16 JUL 85 09:28-EST
From: BRIAN%UOFT02.BITNET@WISCVM.ARPA
Subject: RSX Kermit Warning
A problem with RSX Kermit-11 has been resolved in that the outgoing
line (via SET LINE) must NOT have the /RPA setting enabled (read pass
all). If set, it must be disabled via the mcr command SET/NORPA=TTn:
The characteristic is not one that would be normally set. The effect of
having it set is to force the terminal driver to pass all flow control
(xon and xoff) characters directly to Kermit, which is highly
undesirable. The call to disable /RPA will be added to Kermit-11 source
in the future.
------------------------------
Date: Tue, 16-JUL-1985 08:55 EDT
From: Ronald A. Jarrell <JARRELLRA%VPIVAX5.BITNET@WISCVM.ARPA>
Subject: Kermit for Mac L Running Unix
Our CS department is going to be having all incoming freshman purchasing
Macintosh-L's with Unipres System V. Has anyone tested, or suspects that
one of the flavors of kermit will work under that combination? We plan on
setting up some semi-automated software for file transfer for them, and the
most desirable alternative would be for them to connect to a VMS Vax that
has Kermit on it.
-Ron Jarrell
Systems Programming Dept,
Va Tech
------------------------------
17-Jul-85 11:36:50-EDT,869;000000000001
Mail-From: EXT1.FUCHS created at 17-Jul-85 11:36:47
Date: Wed 17 Jul 85 11:36:46-EDT
From: Michael Fuchs <EXT1.FUCHS@CU20B.ARPA>
Subject: Terminal Emulator w/Kermit: Beta-test Site Query
To: info-kermit@CU20B.ARPA
Would anyone in net.land be interested in beta-testing the latest release
of a commercial terminal emulator (full VT102) for the IBM PC incorporating
a complete implementation of Kermit?
Features include:
* Kermit including CRC, server commands, etc.
* XMODEM, Proprietary protocols with host software provided
* Software (and hardware) 132 column support
* Scrolled-off screens capture buffer (80 screens' worth)
* Terminate-stay-resident Hot key feature
* Programmable softkeys
Anyone interested please contact me through net mail or at 212-777-6707.
Michael Fuchs
Coefficient Systems Corp.
------------------------------
Date: Thu 18 7 85 23:30 GMT
From: Eberhard W. Lisse <zdv626@djukfa11.bitnet>
Subject: MS-Kermit 2.26 and Hercules Graphik Card
Have you heard of any problems caused by the Hercules monochrome graphik card
on an XT DOS 2.11 ?
Since they installed it on our XT, Kermit does not connect any more.
[Ed. - Can anyone help?]
------------------------------
End of Info-Kermit Digest
*************************
-------