postel@VENERA.ISI.EDU (06/30/88)
Hi. The Telnet defaults will not be changed. Not ever. Additional Telnet Options are very likely. --jon.
BILLW@MATHOM.CISCO.COM (William Westfield) (07/06/88)
I may be flamed at for suggesting this (and perhaps deservedly so), but I really wish telnet had a "DON'T TELNET-ANYMORE" option. Most telnet server/client interactions happen at connection startup, and then they stay the same until the connection closed. Unfortunately, since telnet options can occur anywhere within the data stream, both telnet processes have to carefully examine every character to see whether it might be an IAC. I wish a host could set the connection up the way that it wanted, and then say "that's it, no more telnet negotiations from me". (Of course, this would make the most sense in binary mode, so that you would not have to worry about end-of-line nonsense either.) Any comments? Bill Westfield cisco Systems. -------
mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (07/06/88)
Are you suggesting that one eliminate line mode and only use binary mode? Or are you suggesting that there be an integration of TELNET and the local systems terminal driver? Merton Campbell Crockett
braden@VENERA.ISI.EDU (07/06/88)
Bill, There are Telnet controls (eg IP, AO, AYT...) that can appear at any time in the stream, and a correct implementation must check for them. An implementation that does not is not implementing the Telnet protocol (RFC-764). Bob Braden
mar@ATHENA.MIT.EDU (07/07/88)
A "DON'T TELNET ANYMORE" option can save you a whole lot on efficiency. I don't just mean taking a couple of conditionals out of the main loop in a telnet server. For example, on the ITS operating system, the supdup server was only involved in starting up a connection. Once the connection was established, a system call tied the network connection to the pseudo-tty that the command interpreter was on, and the server process was no longer in the loop. If there was a way to make sure that no more telnet options processing would need to be done, a similar thing could be done with telnet on other operating systems, saving 2 process-switches per character. -Mark
MRC@PANDA.PANDA.COM (Mark Crispin) (07/07/88)
The performance problem you refer to (2 process switches/character) is an artifact of the design of the Telnet server and operating system and not a problem in the Telnet protocol itself. In WAITS, Tenex, and TOPS-20, the Telnet server is in the same context as the terminal driver (that is, it is part of the operating system). A Telnet terminal is a special type of software terminal. It is not a pseudo-terminal because there is no controlling job. It's more like a physical terminal, but instead of the characters coming from a hardware RS232 line scanner they're coming from the TCP/IP driver. I believe a similar design is used by Unix; I don't believe Unix has a Telnet server running at process level. -------
hrp@rothko.CRAY.COM (Hal Peterson) (07/07/88)
Mark, But who is going to take care of NVT if not a telnet server? A very lightweight telnet server perhaps. . . . Hal
08071TCP@MSU.BITNET (Doug Nelson) (07/07/88)
Since Bill Westfield asked for flames: :-) >I really wish telnet had a "DON'T TELNET-ANYMORE" option. Most telnet >server/client interactions happen at connection startup, and then they >stay the same until the connection closed. Unfortunately, since telnet >options can occur anywhere within the data stream, both telnet processes >have to carefully examine every character to see whether it might be an >IAC. I wish a host could set the connection up the way that it wanted, >and then say "that's it, no more telnet negotiations from me". (Of course, >this would make the most sense in binary mode, so that you would not have >to worry about end-of-line nonsense either.) > >Any comments? Why use Telnet if you don't want it? It certainly isn't that difficult to keep scanning for IAC, and Telnet is certainly not a very complex protocol. And you always have the option of rejecting any changes in options if you don't want to deal with them. In what circumstances would you want to use this feature? In a general interactive environment, it would seem like you'd want to keep your options open. What concerns me, though, is that some Telnet implementations apparently assume that no more options will be negotiated after the startup, and then stop working when they encounter software that sends them, such as echo toggles for password suppression. Doug Nelson Michigan State University Computer Lab
jqj@HOGG.CC.UOREGON.EDU (07/07/88)
>From: braden@venera.isi.edu >There are Telnet controls (eg IP, AO, AYT...) that can appear at any time >in the stream, and a correct implementation must check for them. An >implementation that does not is not implementing the Telnet protocol >(RFC-764). This is precisely Bill's point. He argues that in some applications the higher level protocol knows that it will never generate or listen to such controls after a particular point in the session, and therefore could improve efficiency by saying "don't bother to check any more", but can't unless the Telnet protocol definition were changed. This seems to me to be one of many possible negotiable "performance options". One might also have negotiations that specified typical chunk sizes for transmissions (e.g. size of the Unix write() buffer. In no way related to MSS or anything like that, obviously) -- useful in helping the receiver do buffer management, expected average data rate, expected connection lifetime, ad nauseum. I don't believe that Telnet should implement any such negotiations because I see them all as minor performance tuning that greatly complicates the protocol. But I do think they should be considered as a group since they all share the characteristic that the applications protocol knows something about the stream traffic pattern that doesn't help the TCP level very much, but might help the remote applications level. Now, a LAT-like protocol that multiplexed several virtual terminal sessions (perhaps several telnet streams?) on a single sequenced packet protocol connection. THAT would be something to more seriously investigate as a standardized performance enhancement for connecting IP terminal servers to hosts.
brescia@PARK-STREET.BBN.COM (Mike Brescia) (07/08/88)
A "DON'T TELNET ANYMORE" option can save you a whole lot on efficiency.
Yes, making a direct path from the net driver to the terminal driver is much
more efficient. You do need the escape route however. 10 years ago (or was
that when it was done in ITS) there was talk of having the telnet server throw
such a switch, which meant "pass everything transparently between terminal and
net until you see a special character". That would be IAC in the direction of
net->term and one of BREAKSET in the term->net direction. Once the escape
character was encountered the server would have to interpret again, until it
was satisfied to put the path in transparent mode again.
If there was a way to make sure that no more telnet options processing
would need to be done, a similar thing could be done with telnet on
other operating systems, saving 2 process-switches per character.
Since there is always option processing going on, you just invoke the server
for the characters it needs to handle. IAC-IAC doubling would be expensive,
but how often do you transfer the character 0xFF?
Regards,
Mikehedrick@athos.rutgers.edu (Charles Hedrick) (07/08/88)
Unfortunately Mark is for once giving Unix more credit than it is due. Berkeley's TCP/IP includes a telnetd that runs as a user process. It reads characters from a net connection and copies them into a pty, and visa versa for the echo. There is kernel support available that makes this unnecessary, but as far as I know, the only vendor that has decided to distribute this code is Pyramid (and it isn't released yet). This makes an enormous difference to responsiveness of a telnet connection on a heavily loaded machine. So it's worth doing on our Pyramid timesharing systems. It has not seemed necessary for our other systems (primarily Suns), which are either single-user or have only a few users. In my opinion the best implementation (which is what our Unix code does) is a combination of the two approaches. There is a telnet daemon. It is used to do connection opening and closing and handles all option and control sequence processing. It uses an ioctl to crosspatch the network to the pty. The kernel then handles passing characters as long as they are "easy". When it detects an IAC from the network (the beginning of a telnet option of some sort), the crosspatch is broken and control returns to the daemon. Thus the kernel handles the normal case, for which performance is important, but need not be complicated by negotiations, etc. This code is available, but so far no one has reported success in getting it to run on machines other than the Pyramid and some other unnamed system which I assume is not a VAX. A number of people have taken copies of it and not told me the results. I'd be happy to send it to you, but only if you are serious about doing the kernel work necessary to get it to work, and telling me the results.