[ Previous ] [ Next ] [ Index ] [ C-Kermit Home ] [ Kermit Home ]
Article: 11026 of comp.protocols.kermit.misc
From: email@example.com (Frank da Cruz)
Subject: Case Study #12: C-Kermit's Telnet Client
Date: 20 Jan 2000 23:23:13 GMT
Organization: Columbia University
These days it seems that blessings are always mixed. Everything's a tradeoff. The evolution of the Telnet protocol is no exception. Primarily to accommodate modern demands for security, the original simple protocol set forth in RFC854 (1983) is no longer sufficient. C-Kermit 7.0 includes a fully modern Telnet implementation, complete with tradeoffs.
On the plus side, the C-Kermit Telnet client can handle authentication securely using any of several different authentication methods; it can verify the identity of the host you are connecting to, and it can also encrypt your session and (more about all this in future installments).
On the minus side, initial connection can take a bit longer than before because there's more to negotiate, and because of the time taken by reverse Domain Name Service (DNS) lookups, which client and/or server might initiate. Sometimes connections can take a lot longer. The most common causes of long delays are:
C-Kermit> telnet /nowait oldmini.xyzcorp.com
The risk is that client and server might have conflicting ideas about certain parameters that are supposed to agree, which can result in fractured sessions (or worse if you are trying to make a secure connection; more about this in a future posting).
These hints should get you past any new difficulties you might have experienced when upgrading to C-Kermit 7.0 from prior versions. Of course there is much more to tell. C-Kermit's Telnet protocol interpreter has been entirely redesigned and recoded to handle most modern options and to give you total and detailed control over negotiation policies and a