kre@cs.mu.oz.au (Robert Elz) (11/02/88)
While this discussion on telnet has been most interesting, I don't think that its entirely relevant to the original question, which related to rlogin support in terminal servers. The most likely reason for wanting "rlogin support" in a terminal server is 100% unrelated to protocols, automatic login (which is typically not applicable anyway) , terminal type negotiation, or any of the rest of all of this "can telnet really do ...?" stuff. The real reason is that users have become trained that the way one connects to a destination host is by using rlogin host and that after that everything that is typed is sent to the remote end, until the sequence <cr>~. after which the connection is broken, or until <cr>~^Z which returns to the originating node, without breaking the connection. If the terminal server implements that functionality, the actual protocol that's used underneath will be irrelevant for 99% or users. So, terminal server vendors, please do implement "rlogin", however, by all means, if you want to, simply make it a front end to your telnet client, which disables the return to telnet command mode magic character, and implements the '~' sequences above. Just don't advertise it as supporting "rlogin" unless you really do. This is also likely to be the way that Berkeley can really get rid of "rlogin" once the telnet client/server support all the required functionality, the rlogin client can just become a modified telnet, which does suitable negotiation to appear to be rlogin to the user. Getting rid of the other r* commands will be rather harder (I suspect rcp would need several ftp extensions before rcp could be seen as an ftp alias, and rsh has no real alternative at all that I know of). kre ps: while discussion differences between telnet and rlogin, its useful to remember that telnet client implements a virtual terminal for the server, whereas rlogin implements a virtual DB25 socket... (or did when it was created, its a little fancier now).
haas@wasatch.UUCP (Walt Haas) (11/05/88)
In article <1020@murtoa.cs.mu.oz.au>, kre@cs.mu.oz.au (Robert Elz) writes: > The most likely reason for wanting "rlogin support" in a terminal > server is 100% unrelated to protocols, automatic login (which is > typically not applicable anyway) , terminal type negotiation, or > any of the rest of all of this "can telnet really do ...?" stuff. > > The real reason is that users have become trained that the way > one connects to a destination host is by using > > rlogin host I couldn't agree with you less... I don't think anybody around here cares what they have to type to get there, the issue is transparency. The TELNET spec is written so that almost minimal subset, no matter how useless, can be advertised as a TELNET implementation. Combined with a total lack of conformance testing, we have a protocol "standard" that probably does more harm than good. By contrast rlogin code is usually a copy of the Berkeley code so the implementations are a lot more consistent, and the functionality is a lot more transparent to the user. Cheers -- Walt Haas haas@cs.utah.edu utah-cs!haas