Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

Telnet NVT, and facilitate the negotiation and use of options. It is the client and server

devices themselves that decide whether Telnet is used for remote access or for some other

purpose.

Telnet's Legacy

Telnet’s flexibility, combined with its age in the TCP/IP suite, has led to Telnet being adopted

for a variety of other protocols. Since Telnet doesn’t make assumptions about what a client

is and what a server is, any program or application can use it. Many of the file and message

transfer applications, including FTP, SMTP, NNTP and HTTP, communicate through the

sending of text commands and messages, and use the Telnet’s NVT specification to ensure

the compatibility of communication between devices. They don’t actually establish Telnet

sessions or use features like option negotiation, they just send data in a manner consistent

with how Telnet works.

Thus, even though modern Internet users may never intentionally invoke Telnet specifically,

they use it indirectly every time they send or receive e-mail or browse the Web. Adminis-

trators can even use Telnet client software to access devices such as FTP and HTTP

servers and send them commands manually.

Key Concept: Telnet is one of the oldest protocols in the TCP/IP suite, first

developed in the 1960s to allow a user on one computer system to directly access

and use another. It is most often used for remote login, with Telnet client software on

a user’s machine establishing a session with a Telnet server on a remote host to let the user

work with the host as if connected directly. To ensure compatibility between terminals and

hosts that use different hardware and software, communication between Telnet client and

server software is based on a simplified, fictional data representation that can be enhanced

through the negotiation of options.

Telnet Connections and Client/Server Operation

Telnet’s overall function is to define a means by which a user or process on one machine

can access and use another machine as if it were locally connected. This makes Telnet

inherently client/server in operation, like so many other application protocols in TCP/IP.

Usually, the Telnet client is a piece of software that acts as an interface to the user,

processing keystrokes and user commands and presenting output from the remote

machine. The Telnet server is a program running on a remote computer that has been set

up to allow remote sessions.

TCP Sessions and Client/Server Communication

Telnet is used for the interactive communication of data and commands between client and

server over a prolonged period of time, and is thus strongly based on the concept of a

session. For this reason, Telnet runs over the connection-oriented Transmission Control

Protocol (TCP). Telnet servers listen for connections on well-known TCP port number 23.

When a client wants to access a particular server, it initiates a TCP connection to the appro-

priate server, which responds to set up a TCP connection using the standard TCP three-

way handshake.

The TCP connection is maintained for the duration of the Telnet session, which can remain

alive for hours, days, or even weeks at a time. The quality of service features of TCP

guarantee that data is received reliably and in order, and ensures that data is not sent at too

high a rate for either client or server. A machine offering Telnet service can support multiple

simultaneous sessions with different users, keeping each distinct by identifying it using the

IP address and port number of the client.

Since TCP is a full-duplex protocol, both client and server can send information at will over

the Telnet session. By default, both devices begin by using the standard Telnet Network

Virtual Terminal (NVT) method for encoding data and control commands. They can also

negotiate the use of Telnet options to provide greater functionality for the session. While

option negotiation can occur at any time, it is normal for there to be a “burst” of such option

exchanges when a Telnet session is first established, and only occasional option command

exchanges thereafter.

With the TCP connection in place and the Telnet session active, the client and server

software begin their normal jobs of interfacing the user to the remote host. To the user, the

Telnet session appears fundamentally the same as sitting down at a terminal directly

connected to the remote host. In most cases, the server will begin the user’s session by

sending a login prompt to ask for a user name and password. The Telnet client will accept

this information from the user and send it to the server. Assuming the information is valid,

the user will be logged in and can use the host in whatever manner his or her account

authorizes.

As mentioned in the Telnet overview, even though the protocol is classically intended for

remote login, it need not be used in this manner. The administrator of the computer that is

running the Telnet server determines how it is to be used on that machine. As just one

example, a Telnet server can be interfaced directly to a process or program providing a

service. I can recall years ago using an Internet server that provided weather information to

the public using Telnet. After using the protocol to connect to that machine, you would be

presented not with a login prompt, but a menu of weather display options. Of course today,

the Web has replaced most of such facilities, as it is far better-suited to this type of infor-

mation retrieval.

Key Concept: Telnet is a client/server protocol that uses TCP to establish a session

between a user terminal and a remote host. The Telnet client software takes input

from the user and sends it to the server, which feeds it to the host machine’s

operating system. The Telnet server takes output from the host and sends it to the client to

display to the user. While Telnet is most often used to implement remote login capability,

there is no concept specifically pertaining to logins in the protocol, which is general enough

to allow it to be used for a variety of functions.

Use of Telnet To Access Other Servers

The Telnet NVT representation is used by a variety of other protocols such as SMTP and

HTTP. This means that the same Telnet client that allows you to access a Telnet server can

be used to directly access other application servers. All you need to do is specify the port

number corresponding to the service. For example, this command will allow you to directly

interface to a Web server:

telnet www.someserversomewhere.org 80

You will not receive a login prompt, but instead the server will wait for you to send an HTTP

Request message, as if you were a Web browser. If you enter a valid request, the server

will send you an HTTP Response message. Used in this way, Telnet can be very valuable

as a diagnostic tool.

Key Concept: The Telnet Network Virtual Terminal (NVT) data representation has

been adopted by a host of other TCP/IP protocols as the basis for their messaging

systems. Telnet client software can thus be used not only to connect to Telnet

servers, but also to servers of protocols such as SMTP and HTTP, which is useful for

diagnostic purposes.

Telnet Communications Model and the Network Virtual Terminal (NVT)

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

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

The Problem of Differing Representations

Computers back in the “good old days” were highly proprietary, and not designed to interop-

erate. 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 other—just 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 ambas-

sadors 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 wouldn’t need to learn it.

The Network Virtual Terminal

Telnet uses an approach similar to the analogy described above for dealing with its problem

of hardware and software compatibility. Rather than having terminals and hosts commu-

nicate using their various native “languages”, all Telnet clients and servers agree to send

data and commands that adhere to a fictional, “virtual” terminal type call the Network Virtual

Terminal (NVT). The NVT defines a set of rules for how information is formatted and sent,

such as character set, line termination, and how information about the Telnet session itself

is sent.

Each Telnet client running on a terminal understands both its native language and NVT.

When information is entered by the user on his or her local terminal, it is converted to NVT

for transmission over the network in NVT form. When the Telnet server receives this infor-

mation, it translates it from NVT to the format that the remote host expects to receive it. The

identical process is performed for transmissions from the server to the client, in reverse.

This is illustrated in Figure 320.

Key Concept: The Telnet Network Virtual Terminal (NVT) is a uniform data repre-

sentation that ensures the compatibility of communication between terminals and

hosts that may use very different hardware, software and data formats. The Telnet

client translates user input from the terminal’s native form to NVT for transport to the Telnet

server, where it is converted to the host’s internal format. The process is reversed for output

from the host to the user.

The NVT is defined to consist of a logical “keyboard” for input and a logical “printer” for

output (the age of the protocol is reflected in these terms; decades ago there were no

monitors, all output was on paper). NVT uses the 7-bit United States ASCII (USASCII)

character set. Each character is encoded using one 8-bit byte. Note however that a client

and server can use Telnet options to negotiate other data representations, including the

transmission of either extended ASCII or even full 8-bit binary data.

NVT ASCII Control Codes

Regular ASCII consists of 95 regular, “printable” characters (codes 32 through 126) and 33

control codes (0 through 31 and 127). The Telnet standard specifies that the output device

must be able to handle all the printable characters, and it mandates how several of the

other common ASCII control codes should be interpreted. Of these codes, three (0, 10 and

Figure 320: Telnet Communication and the Network Virtual Terminal (NVT)

Telnet uses the Network Virtual Terminal (NVT) representation to allow a user terminal and remote host that

use different internal formats to communicate.

User

Terminal

User Input

In Client

Representation

User Input and Client

Commands in NVT

Representation

User Input

In Server

Representation

Host Output

In Server

Representation

Host Output

In Client

Representation

Host Output and

Server Commands in

NVT Representation

Te lne t

Client

Te lne t

Server

Internet

Te rminal

Operating

System

Host

Operating

System

Remote

Host

13) are required to be accepted by all Telnet software; five others are optional, but if

supported, must be interpreted in a manner consistent with the Telnet specification. They

are all described in Table 281.

End-of-Line Representations

The Telnet NVT scheme defines the combination of the carriage return (“CR”) and line feed

(“LF”) characters to represent the end of a line of ASCII text. The literal meaning of these

two characters is “return to the left margin” (from the “CR”) and “go to the next line” (from

the “LF”). However, NVT treats the “CR+LF” sequence as more than just two independent

characters; they are taken collectively to define a logical “end of line” character. This is

necessary because not all terminal types define an end of line using both “CR” and “LF”.

Translation of end-of-line characters between the native and NVT formats is one of the

functions that Telnet client and server software must perform to ensure compatibility

between terminals and hosts.

Table 281: Interpretation of Standard Telnet NVT ASCII Control Codes

ASCII

Value

(Decimal)

ASCII

Character

Code

ASCII

Character

Description

Support

Optional /

Mandatory

0 NUL Null No operation (no effect on output). Mandatory

7 BEL Bell

Produces an audible or visible signal on the

output without moving the print head. This

notification may be used to get the user’s

attention, as in the case of an error.

Optional

8 BS Back Space

Moves the print position one character to

the left.

Optional

9 HT Horizontal Tab

Moves the printer to the next horizontal tab

stop. The standard does not specify how

devices agree on tab stop positions; this

can be negotiated using Telnet options.

Optional

10 LF Line Feed

Moves the printer to the next line, keeping

the print position the same.

Mandatory

11 VT Vertical Tab

Moves the print line to the next vertical tab

stop. As with the “HT” character, devices

must use an option to come to an

agreement on vertical tab stop positions.

Optional

12 FF Form Feed

Moves the printer to the top of the next

page (or on a display, clears the screen and

positions the cursor at the top.)

Optional

13 CR Carriage Return

Moves the printer to the left margin of the

current print line.

Mandatory

Key Concept: The Telnet NVT format is based on 7-bit US ASCII, with each byte

carrying one character. The standard specifies that devices must handle all standard

printable ASCII characters, as well as three mandatory control characters. Two of

these are the carriage return (“CR”) and line feed (“LF”) characters; when combined, these

define the logical end of a line of text. The Telnet standard also describes the interpretation

of five other optional ASCII control characters.

Half-Duplex and Full-Duplex Modes

Another artifact of the age of Telnet is that for maximum compatibility, the Network Virtual

Terminal specification is designed under the assumption of half-duplex operation: only one

device can transmit at a time. A device that is sending data is supposed to end its trans-

mission with the special Telnet Go Ahead command, telling the other device that it may now

transmit (the next topic describes Telnet protocol commands). This is similar to how people

using walkie-talkies end each transmission with “over” to tell their partner that they may now

respond.

Of course, modern networks operate in a full-duplex mode, and using half-duplex communi-

cation would be needlessly inefficient. In most cases the Telnet client and server agree to

use an option (Suppress Go Ahead) that eliminates the need to send this command.

However, having this as the default is a good example of how NVT acts as a “least common

denominator” in Telnet, in case the simpler operating mode is needed by either device.

Telnet Protocol Commands

Most of the input that a user enters at a terminal takes the form of data and commands that

are sent to the application program he or she is using. However, computer systems also

provide a means by which a user can instruct the terminal to send certain commands that

control how the terminal itself operates, and how it interacts with the computer to which it is

connected. The best example of this is the command to interrupt a process, which is usually

sent by pressing a special key or key combination on the user terminal.

Telnet needs to have a way to allow such commands to be entered by the user. However,

here we run into the same problem that we saw in the last topic, when we talked about the

communication of data between terminals and computers: a lack of uniformity in represen-

tation. While all terminals and computers support the ability to interrupt a running program,

for example, they may each use a different keystroke to represent it. For example, on most

UNIX systems, the key combination “<Ctrl>+C” interrupts a program, but typing this on a

Windows system will not (it usually represents instead the “copy data” function!)

Defining a Universal Representation for Standard Command Functions

Since the problem is the same as the one we ran into in representing data flow, it’s not too

surprising that the solution is the same: the use of a universal representation for a set of

standard commands to be passed between the terminal and host computer. All keystrokes

that represent these commands are translated to the standard Telnet codes for trans-

mission, and then translated to the specific needs of the host computer. So to take our

example again, if a user presses “<Ctrl>+C” on a UNIX terminal where this is defined as the

interrupt function, then instead of sending that exact keystroke, the Telnet client sends the

special Telnet Interrupt Process command, which is translated by the Telnet server to the

command code appropriate for the connected host.

The Telnet standard includes a number of these special codes to allow a user to control the

operation of the remote computer. It also defines a set of commands that are specific to the

Telnet protocol itself; these let the Telnet client and Telnet server software communicate.

Collectively, these are called Telnet protocol commands.

Escaping Commands and the Interpret As Command (IAC) Character

All Telnet commands are sent in the same communication stream as regular data; they are

represented using special byte values in the range from 240 to 254. To differentiate

between data bytes of these values and Telnet commands, every command is preceded by

a special escape character, given the name Interpret As Command (IAC). IAC has a value

of 255; when the recipient sees this character, it knows the next byte is a command and not

data. So, since the Telnet Interrupt Process command has the value 244, to send this

command the Telnet client would transmit the byte 255 and then 244. If the actual data byte

value 255 needs to be sent, it is transmitted as two 255 bytes. Some Telnet commands also

include additional bytes data, which are sent after the command code itself; a good

example is the use of parameters in Telnet option negotiation.

You may be wondering at this point why the IAC character is needed at all. After all, Telnet

uses US ASCII, which is 7-bit data in the byte range of 0 to 127, and the Telnet commands

have values higher than 127. One general rationale for using the IAC escape is to be

explicit that a command is being sent. A more specific reason is to accommodate the

optional sending of 8-bit binary data over Telnet, which the client and server can negotiate.

If this mode were enabled and commands were not preceded by the IAC character, this

would require all data bytes with values from 240 to 255 to be somehow marked so they

would be interpreted as data and not commands. It is more efficient to include an extra byte

for commands than data, since they are sent less frequently. By escaping commands, only

data byte value 255 requires two bytes to be sent.

Key Concept: The Telnet protocol defines a set of protocol commands that are used

for two purposes: first, to represent standard control functions that need to be sent

between a terminal and host, such as the command to interrupt a process; and

second, to enable protocol communication between the Telnet client and server software.

Protocol commands are sent in the normal data communication stream over the Telnet

session’s TCP connection. Each is represented by a byte value from 240 to 254, and is

preceded by the Interpret As Command (IAC) command, byte value 255, which tells the

recipient that the next byte in the stream is a command.

Telnet Protocol Command Codes

Table 282 lists the Telnet protocol commands in numerical byte value order, showing for

each its command code and name and describing its meaning and use.

Table 282: Telnet Protocol Commands (Page 1 of 2)

Command

Byte Value

(Decimal)

Command

Code

Command Description

240 SE

Subnegotiation

End

Marks the end of a Telnet option subnegotiation, used

with the SB code to specify more specific option param-

eters. See the topic on Telnet options for details.

241 NOP No Operation Null command; does nothing.

242 DM Data Mark

Used to mark the end of a sequence of data that the

recipient should scan for urgent Telnet commands. See

the topic on Telnet interrupt handling for more

information.

243 BRK Break

Represents the pressing of the “break” or “attention” key

on the terminal.

244 IP

Interrupt

Process

Tells the recipient to interrupt, abort, suspend or

terminate the process currently in use.

245 AO Abort Output

Instructs the remote host to continue running the current

process, but discard all remaining output from it. This

may be needed if a program starts to send unexpectedly

large amounts of data to the user.

246 AYT Are You There

May be used to check that the remote host is still “alive”.

When this character is sent the remote host returns

some type of output to indicate that it is still functioning.

247 EC Erase Character

Instructs the recipient to delete the last undeleted

character from the data stream. Used to “undo” the

sending of a character.

248 EL Erase Line

Tells the recipient to delete all characters from the data

stream back to (but not including) the last end of line

(“CR”+”LF”) sequence.

249 GA Go Ahead

Used in Telnet half-duplex mode to signal the other

device that it may transmit.

250 SB Subnegotiation

Marks the beginning of a Telnet option subnegotiation,

used when an option requires the client and server to

exchange parameters. See the topic on Telnet options

for a full description.

251 WILL Will Perform

In Telnet option negotiation, indicates that the device

sending this code is willing to perform or continue

performing a particular option.

Perhaps ironically, the Telnet command are not used as much today as they were when

Telnet was in its early days, because many of the compatibility issues that we discussed

earlier no longer exist. ASCII has become the standard character set of the computing

world, so many of the functions such as aborting output or interrupting a process no longer

require the use of Telnet commands. They are still widely used, however, for internal Telnet

operations such as option negotiation.

Telnet Interrupt Handling Using Out-Of-Band Signaling: The Telnet

Synch Function

All the bytes of data sent from a Telnet client to a server are received in the order that they

were sent, and vice-versa. This is, of course, the way we expect an application to operate;

in fact, ensuring that data is not received out-of-order is one of the jobs that we assume of

the reliable transport protocol TCP, over which Telnet runs. However, this can cause a

problem for Telnet because of the way the protocol sends both data and commands over

the same connection.

The Problem: Sending an Interrupt Command

The most important case where the issue of all data being received in order arises is when

a user needs to interrupt a process. Suppose as an example that you are using Telnet to

run an interactive program that takes user input, processes it, and then produces output.

You are merrily typing away when you notice that you haven’t seen any output from the

program for a while. It has apparently hung up due to a programming error or other glitch.

252 WON’T Won’t Perform

In Telnet option negotiation, indicates that the device

sending this code is either not willing to perform a

particular option, or is now refusing to continue to

perform it.

253 DO Do Perform

In Telnet option negotiation, requests that the other

device perform a particular option or confirms the expec-

tation that the other device will perform that option.

254 DON’T Don’t Perform

In Telnet option negotiation, specifies that the other party

not perform an option, or confirms a device’s expectation

that the other party not perform an option.

255 IAC

Interpret As

Command

Precedes command values 240 through 254 as

described above. A pair of IAC bytes in a row represents

the data value 255.

Table 282: Telnet Protocol Commands (Page 2 of 2)

Command

Byte Value

(Decimal)

Command

Code

Command Description