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.
Telnet Overview, History and Standards
(Page 2 of 3)
Telnet was the first application
protocol demonstrated on the fledgling ARPAnet, in 1969. The first RFC
specifically defining Telnet was RFC 97, First Cut at a Proposed
Telnet Protocol, published in February 1971. Development of
Telnet continued throughout the 1970s, with quite a number of different
RFCs devoted to revisions of the protocol and discussions of issues
related to it. It took many years to refine Telnet and resolve all the
difficulties that were associated with its development.
The final version of the protocol,
Telnet Protocol Specification, was published as RFC 854
in May 1983. Over the years other RFCs have been published to clarify
the use of the protocol and address various issues such as authentication.
There are also a number of other RFCs that define Telnet
options, as we will see later in this
Fundamental Telnet Concepts
At first glance, it may be surprising
that Telnet took so long to develop, because in theory, it should be
a very simple protocol to define: all it needs to do is send keystrokes
and program output over the network like any other protocol. This would
be true if every terminal and computer used the same communication method,
but they do not. Telnet becomes complicated because it needs to allow
a terminal from one manufacturer to be able to talk to a computer that
may use a very different data representation.
Telnet solves this problem by defining
a method that ensures compatibility between terminal types and computers
while allowing special features to be used by computers and terminals
that agree to support them. The protocol is built upon a foundation
of three main concepts:
- The Network Virtual Terminal (NVT): Telnet
defines a standardized, fictional terminal called the Network Virtual
Terminal (NVT) that is used for universal communication by all devices.
A Telnet client takes input from a user and translates it from its native
form to the NVT format to send to a Telnet server running on a remote
computer; the server translates from NVT to whatever representation
the computer being accessed requires. The process is reversed when data
is sent from the remote computer back to the user. This system allows
clients and servers to communicate even if they use entirely different
hardware and internal data representations. Special Telnet commands
are interspersed with the data to allow the client and server devices
to perform various functions needed to manage the operation of the protocol.
- Options and Option Negotiation: Having
Telnet clients and servers act as NVTs avoids incompatibilities between
devices, but does so by stripping all terminal-specific functionality
to provide a common base representation that is understood by everyone.
Since there are many cases where more intelligent terminals and computers
may wish to use a more advanced communication feature or service, Telnet
defines a rich set of options and a mechanism by which a Telnet client
and server can negotiate their use. If the client and server agree on
the use of an option it can be enabled; if not, they can always fall
back on the NVT to ensure basic communication.
- Symmetric Operation: While Telnet is a
client/server protocol, it is specifically designed to not make assumptions
about the nature of the client and server software. Once a Telnet session
is established, they can each send and receive data as equals. They
can also each initiate the negotiation of options. This makes the protocol
extremely flexible, and has led to its use in a variety of places, as
we will discuss in a moment.
|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!|
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.