C-Kermit 7.0 Case Study #06

[ Previous ] [ Next ] [ Index ] [ C-Kermit Home ] [ Kermit Home ]

Article: 10912 of comp.protocols.kermit.misc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Case Study #6: Streaming
Date: 14 Jan 2000 00:50:40 GMT
Organization: Columbia University

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:

  http://www.columbia.edu/kermit/cuiksd.html

for an introduction.

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.

For more about streaming, read Section 4.20 ckermit2.txt file.

- Frank

[ Top ] [ Previous ] [ Next ] [ Index ] [ C-Kermit Home ] [ Kermit Home ]