One of the goals for C-Kermit 7.0 was to make Kermit file transfer
comparable in speed to FTP on TCP/IP connections. Early experiments using
long packets and large window sizes gave excellent results when certain
platforms were involved. But with other platforms, the results were
discouraging -- throughput was only about 10% of what we expected.

To make a rather long story short, this severe degradation in speed was
caused not by anything in Kermit itself, but rather by the underlying
TCP/IP stack when it implemented certain heuristics such as the Nagle
Algorithm and/or Delayed ACK. These are triggered when the file receiver
sends a Kermit ACK (acknowledgement packet), which is quite short. The
TCP stack hangs on to it for some amount of time -- say 200 milliseconds --
before letting it go, in hopes that by then it will have something more
to transmit.

But 200 milliseconds is a long time on a ten-million-bit-per-second
connection. It's long enough to transmit 2,000,000 bits of data. Once
the file sender is blocked waiting for a delayed Kermit ACK, which happens
as soon as its send window fills up, throughput takes a nosedive.

The only way around this problem is for the file receiver not to send
ACKs. Then the file sender can "stream" the data continuously -- just like
FTP does.

But if the file receiver doesn't send ACKs, there can be no error
recovery. Errors can be detected, but if any occur, they are fatal. But
since it's a TCP/IP connection there are not going to be any non-fatal
errors, by the very definition of TCP.

So we introduced streaming in the latest round of Kermit releases:
C-Kermit 7.0,
G-Kermit 1.00,
Kermit 95 1.1.17, and
MS-DOS Kermit 3.16
(still in Beta). Streaming is used automatically when both Kermit
programs know about it and the Kermit program that made the connection
tells the Kermit program on the far end that the connection is reliable;
then the two Kermits agree to stream. And when they stream, transfers go fast.

Exactly how fast depends on how you made the connection. If it's a Telnet
or Rlogin connection, it's going through several layers of overhead that
FTP doesn't have: the Telnet or Rlogin server -- and the pseudoterminal
and driver -- on the far end. The amount of overhead depends on the
implementation.

On the other hand, if you have a direct socket-to-socket connection
between two Kermit programs, you should get about the same speed as FTP.
How do you get a direct socket-to-socket connection? One way, which is
not terribly convenient, is described on page 127 of "Using C-Kermit" (the
"set host *" method). But now there's a better way: the Internet Kermit
Service (IKSD). We'll talk about that in a future installment, but in the
meantime you can visit:

Streaming can be used not only on TCP/IP connections, but any other
reliable transport, such as X.25. But it is not -- and should not be --
used on serial connections; even if you are using error-correcting modems,
there is no guarantee of reliable transport between the modem and the
application -- for example, there can be flow-control failures.