Please Whitelist This Site?

I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)

If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.

If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.

Thanks for your understanding!

Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide


NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The Book is Here... and Now On Sale!

Enjoy The TCP/IP Guide? Get the complete PDF!
The TCP/IP Guide

Custom Search







Table Of Contents  The TCP/IP Guide
 9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)
      9  TCP/IP Key Applications and Application Protocols
           9  TCP/IP Interactive and Remote Application Protocols
                9  Telnet Protocol

Previous Topic/Section
Telnet Protocol
Previous Page
Pages in Current Topic/Section
1
23
Next Page
Telnet Connections and Client/Server Operation
Next Topic/Section

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 reasons—most notably, the protocols are easier to understand this way—this 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.

The Motivation for Telnet's Development

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 user’s 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.


Previous Topic/Section
Telnet Protocol
Previous Page
Pages in Current Topic/Section
1
23
Next Page
Telnet Connections and Client/Server Operation
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



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.