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 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

Telnet Protocol 1 2 3 Telnet Connections and Client/Server Operation

Telnet History

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 section.

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.

Telnet Protocol 1 2 3 Telnet Connections and Client/Server Operation