MRC%PANDA@SUMEX-AIM.STANFORD.EDU.UUCP (02/13/87)
I'd like to thank Rudy Nedved for the complement ("the best
implementation [of TELNET] (ignoring performance) seems to be TOPS-20")
since I wrote the TOPS-20 client TELNET. After having written three
client TELNET implementations for different operating systems and a
server TELNET, it sort of rubs off on you.
I would not say that the TOPS-20 server TELNET is anything to
rave about though. It is unnecessarily complicated and has several
major bugs. To my knowledge, the only implementation of TOPS-20
server TELNET that *correctly* implements TELNET protocol is the
one on SIMTEL20, STL-HOST1, and DREA-XX. The typical bugs are the
ones Rudy noted: incorrect implementation of binary mode, EOL's, and
FFh data characters. Some systems, such as Stanford and CMU, have
some half-assed fixes to some of these bugs; but a comprehensive fix
has been stymied to date. It is also pretty poor that few systems
allow user program control of network binary mode. Certain programmers
have gone as far as exploiting a bug with incorrect handling of FFh
data characters to send TELNET protocol as data!
TOPS-20 client TELNET performs well; I think Rudy's performance
comment was aimed at the server. My advice to implementors is:
. you must take NO for an answer in any option
. you must never confirm a negotiation to a state you are already in
. run your streams in separate processes
. never block for a protocol negotiation
. do buffered instead of byte I/O and allocate very large buffers
. fix your operating system's handling of Urgent data so it reliably
works, and make your TELNET implementation use it.
My favorite way of handling options is to SET the option state
when I send a protocol command and proceed as if the host confirmed.
The host will either:
. confirm it, in which case all is well
. do nothing, in which case you're still operating
. deny it, in which case you clear the option and respond
It isn't all that bad to be mistakenly in remote echo to a system that
refuses to do so for a few seconds.
This isn't quite according to spec, but it is a LOT better than a
bogus implementation of the protocol! Entirely too many bogus protocol
implementations are out there.
-------