| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Telnet Communications Model and the Network Virtual Terminal (NVT) (Page 1 of 4) At its heart, Telnet is a rather simple protocol. Once a TCP connection is made and the Telnet session begins, the only real task that the client and server software has is to capture input and output, and redirect it over the network. So, when the user types a key on his local terminal, the Telnet client software captures it and sends it over the network to the remote machine. There, the Telnet server software sends it to the operating system, which treats it as if it had been typed locally. When the operating system produces output, the process is reversed: Telnet server software captures the output and sends it over the network to the users client program, which displays it on the printer or monitor. To invoke two well-known clichés, I could say that this looks good on paper, but that the devil is in the details. This simplified implementation would only work if every computer and terminal used the exact same hardware, software and data representation. Of course, this is far from the case today, and was even worse when Telnet was being developed. Computers back in the good old days were highly proprietary, and not designed to interoperate. They differed in numerous ways, from the type of keyboard a terminal used and the keystrokes it could send, to the number of characters per line and lines per screen on a terminal, to the character set used to encode data and control functions. In short, computer A was designed to accept input in a particular form from its own terminals, and not those of Computer B. This is actually a fairly common issue in the world of networking, and one to which we can draw a real-world analogy to help explain the problem and how it may be solved. Suppose that an important international conference was attended by 30 ambassadors from different nations, each of which had one assistant. Every ambassador and assistant pair spoke only their own language and thus could only speak to each otherjust like a computer and terminal designed to interface only to each other. To allow the assistant from one country to speak to the ambassador from the others, one solution would be to train the assistants to speak the languages of all the other attending nations. Back in the computing world, this would be like defining the Telnet protocol so that every Telnet client software implementation understood how to speak to every computer in existence. In both cases, this would work, but would be quite impractical and difficult to do. An alternative approach is to define a single common language and have all the ambassadors and assistants learn it. While this would require some work, it would be a lot less than requiring people to learn dozens of languages. Each ambassador and assistant would speak both his or her native language and this chosen common language. Each could communicate with all of the others using this common language, without having to know all of the languages that might be used by anyone at the conference. Even more importantly, if an ambassador and assistant showed up at the conference speaking a new, 31st language, all the other delegates wouldnt need to learn it.
Home - Table Of Contents - Contact Us The TCP/IP Guide (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. |