| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Telnet Overview, History and Standards (Page 1 of 3) The description of internetworking protocol suites such as TCP/IP is most often done from the lower layers working upward, just as I have done in this Guide. While this makes sense for a number of reasonsmost notably, the protocols are easier to understand this waythis does not reflect the history of how many protocol suites were developed. Applications in fact often come first: they are defined to meet the needs of users, and the rest of the suite is developed to enable the application to run. Telnet and TCP/IP represent a good example of this top-down process. The history of Telnet actually goes back over a decade before the modern TCP/IP protocol suite that we know today. As I mentioned in my overview of the File Transfer Protocol (FTP), the early developers of TCP/IP internetworking technologies identified two overall application needs for networks to fill: enabling direct access and indirect access to resources. FTP was created for indirect access, by allowing a user to retrieve a resource from a remote host, use it locally, and if desired, copy it back to its source. Telnet was designed for direct access: to let a user access a remote machine and use it as if he or she were connected to it locally. Understanding why Telnet was needed requires us to remember the nature of computing at the time the protocol was initially developed: the late 1960s. This was well before the era of the small personal computers that so many of us use exclusively today. All computers of that period were large and usually shared by many users. To work on a computer, you had to access a physical terminal connected to that machine, which was usually specially tailored to the needs and requirements of the host. There were two specific issues that resulted from this situation. The first was that if you had several different computers in an organization, each user would need a separate terminal to access each computer he or she needed to use. This was expensive and inefficient; I can recall reading a quote from a book that compared this situation to having a room containing a number of television sets, each of which could only display a single channel. The second and perhaps more significant issue was the difficulty in allowing a user at one site to access and use a machine at another. The only method at the time for accomplishing this was to install a dedicated data circuit from the site of the computer to the site of the user, to connect the users terminal to the remote machine. Again, each circuit would only enable access to one machine. Every combination of user and computer would have required a separate, expensive circuit to be installed and maintained. The solution to both of these issues was to create a more general way of allowing any terminal to access any computer. The underlying internetwork would provide the mechanism for communicating information between computers; this became the physical network connecting sites and the TCP/IP protocol suite connecting networks. On top of this would run an application protocol that allowed a user to establish a session to any networked computer and use it: the Telnet protocol.
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. |