RFC854-TELNET (Protocol Specification)

Note: This article fixes a few translation issues based on the translation of the interactive publishing network. In view of my e-level, it does not rule out the possibility of worse Translation after the change. The original copyright information is as follows:

Organization: China Interactive publishing network (http://www.china-pub.com /)

RFC document Chinese Translation Plan (http://www.china-pub.com/compters/emook/aboutemook.htm)

E-mail: ouyang@china-pub.com

Copyright: The copyright of this Chinese translation document belongs to China Interactive publishing network. This document can be freely reproduced for non-commercial purposes, but the translation and copyright information of this document must be kept.

 

The text is as follows:

 

Network Working Group J. Postel

Request for comments: 854 J. Renault

ISI

Obsoletes: Nic 18639 May 1983

1. Introduction

Telnet aims to provide a common, bidirectional, and eight-byte communication mechanism. Its main goal is to allow a standard method to connect terminal devices and Processes targeting various terminals. As you can imagine, this protocol can also be used for inter-terminal communication ("Link") and inter-process communication ("Distributed Computing ").

2. General provisions

A telnet connection is a TCP connection used to transmit data with telnet control information.

The telnet protocol is designed based on three aspects: 1. The concept of network virtual terminal; 2. The principle of option negotiation; 3. Equal view of terminals and processes.

1. When a telnet connection is established, both ends are sent as a "network virtual terminal (nvt)" and closed. An nvt is a representative of a standard terminal that provides standard, network range, and intermediate specifications. This eliminates the need for "servers" and "users" to save information related to the peer terminal and terminal processing agreement. All Hosts, including users and servers, map their local device properties and protocols to nvt on a network, and assume that the other party has a similar ing. Nvt tries to strike a balance between over-constraints (not providing enough vocabulary to the host to map to their local character set) and over-tolerance (limiting the user to use the appropriate terminal.

Note: "user" refers to hosts with physical terminals, and "server" refers to machines that can provide some services. Another similar view (also applicable to end-to-end and process-to-process communication environments) Is that "user" refers to the machine that initializes the communication connection.

2. the principle of Option Negotiation is based on the fact that many hosts want to provide more services on nvt, and many users will have a more complex terminal, in addition, we hope to get first-class services, rather than a few services. Although they are independent of each other, there are many "options" in the Telnet protocol. The accepted options are similar to "do, don't, Will, the won't structure is used together to allow users to negotiate with the server to use more complex (or different) Conventions on their Telnet connections. These options include changing the character set and echo mode.

The basic policy used to set options is to allow each party (or both parties) to initiate a request that makes some options valid, and the other party can accept or reject the request. If the request is accepted, the option takes effect immediately. If the request is rejected, the related features remain consistent with the nvt default. Obviously, one party can always reject requests that enable an option, but should not reject any requests that disable an option, because both parties should support nvt.

We have established a set of rules for negotiation options.

If both parties request the same option at the same time, each party can regard the request of the other party as a positive response to its own request.

3. the symmetry of negotiation syntaxes may lead to endless response loops-Each Party regards the commands sent by the other party as a request that must be answered rather than the response of the other party. To prevent such loops, you can apply the following rules:

A. One party can only request to change the status of the option. That is, one party cannot send a request that only declares the mode in which it is used.

B. If one party receives a request requesting it to enter the current status, the request will not be answered. It is important to prevent endless loops. All requests that change the pattern require a response-although the pattern does not change.

C. whenever an option command is sent to the second party, whether the command is a request or a response, in addition, this option will affect the production processing of data sent from the first party to the second party. Therefore, you must insert this command to the point in the data stream that it wants to start working on. (Note that it takes some time to send a request and receive a response that may be a negative response. Therefore, a host may want to buffer the data to be sent after sending the option request until it knows whether the request is accepted or rejected, to hide the time that is "uncertain" for the user .)

The option request is sent back and forth many times at both ends of the connection when the Telent connection is just established. Each party tries to obtain the best service from the other party. In addition, the option can also be used to dynamically change the connection feature so that it is consistent with the change to the local status. For example, the transfer method used by nvt (to be explained later) is more suitable for "each row" applications.Program(For example, basic), but not suitable for applications with "one character each time" (for example, NLS ). If it is suitable for local processing, the server may accept the huge processor overhead required for "one character each time" and negotiate a proper option. However, when careful control is no longer needed, you can switch back to the state under nvt (through negotiation) to reduce overhead.

If a process only requests the option again after receiving a denial response, the request initiated by a process will be in a loop. To prevent such a loop, you cannot repeat rejected requests unless the situation has changed. In reality, this may mean that the process runs another program, the user has issued another command, or all other context that will affect the process and its options. Based on experience, the re-request should be followed by a response from the other end of the connection, or manually triggered by a local user.

The option designer should not stick to the limited syntax in option negotiation. The intention of using simple syntax is to make options easy to use-because it is easy to ignore them. If some special options require a more complete negotiation structure than "do, don't, will, won't", a better method is to use "Do, don't, will, won't "to determine that both parties can understand this option, and then they can freely use a more special syntax. For example, one party can send a request to notify (create) the length of a row. If this request is accepted by the other party, we can use another different syntax to negotiate the actual length of a row. For example, a "subnegotiation" may include the allowed minimum and allowed maximum values, and the length of the most appropriate row. A more important principle is that such extension negotiations can only begin when some of the previous (standard) negotiations have been established and both parties can interpret these extension syntaxes.

In short, "Will XXX" is sent by both parties to declare that the party wants (to provide) to start processing the option XXX. Do XXX and don't XXX indicate their positive and negative responses. Similarly, do XXX sends out an instruction (request) to the other party (that is, the receiver of DO) start to process the option XXX. Will XXX and won't XXX indicate a positive and negative response.

Because no option is used, nvt ensures that the connection is in a State that can be processed by both parties by using don't and won t responses. Therefore, all hosts should implement their Telnet process like this: simply reject any incomprehensible request for this option without knowing any unsupported options.

The telnet protocol is as symmetric as possible between the server and the user to easily and naturally include the user to the user (connection) and server to the server (Collaborative processing. Although it is not completely necessary, we also hope that the options can enhance this purpose. In any case, symmetry is an operational principle, not a constant standard, which is accepted.

For more information about how to create new options, see the related documentation "Telnet Option specifications.

3. Virtual Network Terminal

A network virtual terminal (nvt) is a bidirectional character device. Nvt has a printer and a keyboard. The printer is responsible for the incoming data, and the keyboard is responsible for generating the data sent out through the telnet connection, and when the "Echo" is required, the data is also displayed on the nvt printer. "Echo" does not require data to pass through the network (although there is an option to control the "remote" mode of this operation, the host is not required to implement this option ).

Except as described here, all encoding sets have eight bits, but only use the seven-bit usascii code. AllCodeThe conversion and time zone problems are both local, without affecting nvt.

4. Data Transmission

Although a network-connected Telnet connection is essentially full-duplex, nvt is usually considered as a half-duplex device in linear buffer mode. That is to say, unless you have negotiated with the other party, the following terms (default) apply to data transmission over Telnet connections:

1) data can be collected on the machine that generates data within the available range of the local buffer space until the complete data row is ready for transmission, or some locally defined signals explicitly require data transmission. These signals can be generated by processes or users.

The motive for defining this rule is that, for some hosts, It is very costly to handle network input interruptions. In addition, the default nvt specification specifies that "echo" does not pass through network transmission. Therefore, there is a reason to buffer some data on the source that generates the data. Many systems perform some operations after entering a row (this is often the case for row printers or card punchers), so data transmission can be triggered when a row of data ends. In addition, sometimes the user or process will find it necessary or should provide data before it reaches the row; therefore, the implementer should pay attention to providing a local signal mechanism to ensure that all buffered data can be sent immediately.

2) When a process is completed, data is sent to an nvt printer, and no data from the nvt keyboard needs to be further processed in the input queue (that is, when one end of the Telnet connection cannot be processed without data input from the other end, the process must transmit the "go ahead, Ga" command.

This rule does not require all terminals on both ends of a connection to send the Telnet ga command, because when the server starts processing, generally, no special signal is required (as well as the disconnection signal and other features defined locally ). Specifically, Telnet GA is designed to help users operate a physical half-duplex terminal on a local computer with a "lockable" keyboard (such as ibm2741. Instructions for such terminals may be helpful for interpreting the correct usage of the GA command.

The connection from the terminal to the computer is always under the control of the user or computer. Neither party can unilaterally gain control of the other party, and the party that obtains control must give up its control explicitly. On the terminal side, the hardware should support the end of each line (that is, when the user presses the "New Line" key), it will give up control. In this case, the connected (local) computer processes the input data and determines whether to generate the output. If not, the control is returned to the terminal. If output is to be generated, the computer maintains control until all output is transmitted.

The difficulty of using this type of terminal through the network is obvious. After a local computer sees a line termination signal, it cannot decide whether to maintain control. This decision can only be made by a remote computer that processes the data. Therefore, the GA command in Telnet provides a mechanism for "remote" computers (servers) to send signals to "local" computers (users, tell the other party that the current control time is passed to the user terminal. It should and should be transmitted only when control should be granted to end users. Note: passing the GA command too early will cause the output to be blocked. Therefore, the user may think that the transmission system has been suspended, which will cause the user to fail to switch to the connection manually.

Of course, the above mentioned situation will not occur when the user goes to the server during the communication process. In this direction, GA can be sent at any time, but this is not necessary. Similarly, if the telnet connection is applied in the process-to-process communication, Ga does not need to be sent in both directions. Finally, GA can be required for communication between the terminal and the terminal in both directions. If a host is intended to support terminal-to-terminal communication, it is recommended that the host provide a method to manually send signals to users when sending ga via Telnet connection. However, it is not necessary to implement Telnet.

Note: Due to the symmetry of the Telnet model, theoretically, each end of a telnet connection must have an nvt.

5. Standard representation of control functions

As described in this document, the main goal of the Telent protocol is to provide a standard interface between the terminal device connected through the network and the terminal-oriented process. Early experiments with this interconnection nature show that most servers have implemented some functions, but the methods to call these functions vary greatly. These differences can be frustrating for a user who wants to interact with multiple server systems. Therefore, the Telnet protocol defines five standard representations of these features. These standard representations have a standard meaning-but are not necessary (except for interrupting the process (IP) function, other protocols using the Telent protocol may need this function ). That is to say, a system that does not provide a certain function to local users does not need to provide this function to other users on the network, and the standard expression of this function can be treated as No. On the other hand, if a system already provides this feature to local users, it must provide the same functionality to those users on the network who transmit this feature.

Interrupt process-interrupted process (IP)

Many systems provide the function of suspending, and terminating user processes. This feature is often used when the user is sure that his process has entered an endless loop, or accidentally activated a process that does not want to be activated. IP is the standard representation of calling this function. The implementers of this function should note that IP addresses may be used for other protocols using the Telnet protocol. Therefore, to support these protocols, this function should be implemented.

Interrupt output -- abort output (AO)

Many systems provide the ability to allow a process that is generating output to run without sending output to the user's terminal (or to a stop point that will arrive after the execution is completed).

In addition, a typical purpose of this function is to clear the output that has been generated but has not been actually printed (or displayed) to the user's terminal. AO is the standard expression for calling this function. For example, many subsystems usually accept a user's command, and then respond with a long string sent to the user terminal. Finally, send a "prompt" (followed by <CR> <LF>) to your terminal to accept the next command. If the AO is received while the string is being transmitted, a reasonable implementation should stop transmitting the string, and turn to the sending prompt and the <CR> <LF> that follows. (This may be different from the actions taken when an IP address is received. When an IP address is received, the transmission of the string is stopped and exited from the subsystem .)

At the same time, it should be noted that for those servers that provide this function, you may also need to clear the contents of the buffer mechanism outside the system (in the network or on the user's local machine. An appropriate way to complete this process is to send a "synchronous" signal to the user's system (as described below ).

Are you there? -- Are you there (ayt)

Many systems provide users with some visible (such as printable) signs that the system is still running. This function can be used when the system is not dynamic for a long period of time that cannot be imagined (probably because the user has not imagined the computing time, or an abnormal huge system load .) Called by the user. Ayt is the standard representation of calling this function.

Remove one character-erase character (EC)

Many systems provide the ability to delete the last character of the "Print position" in the data stream before the undeleted characters or the user-provided data streams. This function is usually used when incorrect characters are entered during keyboard input. EC is the standard representation of calling this function.

* Note: A "Print position" may contain several overlapping characters, or the following character series: <char1> BS <char2>...

Delete a row -- Erase line (EL)

Many systems provide the ability to delete all data of the current row on the output device. This function is often used for input and editing on the keyboard. El is the standard expression for calling this function.

6. "synch" signal in Telnet

Many time-based systems provide a mechanism to allow end users to regain control over "out of control" processes. The IP address and AO function described above are examples of this mechanism. When used locally, such a system can access all signals provided by users, whether these signals are common characters or "out-of-band" signals sent by the "break" key in the telex typewriter or the "Attn" key in IBM 2741. However, this may be incorrect when the system is connected through the network. The Flow Control Mechanism of the Network may buffer these signals to other places, such as the user's machine.

To solve this problem, the "synchronization" mechanism in Telnet is proposed. A synchronization signal contains a TCP emergency notification with the Telnet command data mark. The emergency notification is not affected by the traffic control of the Telnet connection. The process that receives the emergency notification uses it to call the special processing process of the data stream. In this mode, you will immediately start to scan the data stream, find some "interesting" signals defined below, and discard the data in the period.

The Telnet command data mark (DM) is the synchronization mark in the data stream, indicating that a special signal has been generated, and the receiver can continue to process the data stream in general.

The synchronous signal is sent through the sending operation in TCP. Its emergency flag is set to "true", and DM is the last (or unique) byte.

When many synchronous signals are sent continuously, You can merge emergency notifications. The number of emergency notifications cannot be calculated because the number of emergency notifications received may be equal to or less than the number of sent notifications. In normal mode, a DM does not have any operations, but in emergency mode, it indicates the end of the emergency process.

If TCP indicates the end of the emergency data before DM is found, telnet should continue to process the data stream until DM is found.

If more emergency data is indicated by TCP after DM is found, it can only be another synchronous signal. Telnet should continue to process the data stream until another DM is found.

An "interesting" signal is defined as the standard representation of IP addresses, AO, and ayt (excluding EC or El) in Telnet; local representation (if any) similar to these standard representations; all other Telnet commands; other custom signals that work and do not delay data flow scanning.

One of the effects of synch mechanisms is to discard all characters that are supposed to be transmitted between the sender and receiver (except for telnet commands). If necessary, this mechanism can be used as a standard way to clear data paths. For example, if a user on a terminal needs to transmit an AO, the server that receives the AO should return a synchronous signal to the user (if it provides this function ).

Finally, in the Telnet layer, a TCP emergency notification must be treated as an out-of-band signal. Therefore, other telnet-based protocols may need to be used as a Telnet command at different levels.

According to the Convention, the sequence [IP, synch] can be used as such a signal. For example, assume that another protocol using the Telnet protocol defines a string like the Telnet command AO stop. Imagine that you want the server to process the stop string, but the connection is blocked because the server is processing other commands. The user should guide his system:

A) send the Telnet IP character;

B) send the Telnet sync series, that is, send the data mark (DM) as a unique character in an emergency mode TCP sending operation.

C) Send out the string stop; then

D) If yes, send commands similar to telnet DM in other protocols.

The user (or process that represents the user) must transmit the Telnet synch series in step 2 above to ensure that the Telnet IP Address has reached the Telnet interpreter on the server.

An emergency notification will activate the Telnet process, and the IP address will activate the later-level processes.

7. nvt printer and keyboard

The nvt printer has a paper dispenser with no specified width and the length of each page is not specified. The nvt printer can generate all 95 usascii-encoded graphical representations (from 32 to 126 ). In 33 usascii encodings (0 to 31 and 127) and other 128 uncontained encodings (128 to 255), the following encodings have limited significance for nvt Printers:

Name	Encoding	Description
NULL (NUL)	0	Null operation
Line feed (LF)	10	The print header is moved to the next print line without changing the horizontal position of the print header.
Carriage Return (CR)	13	Move the print header to the left of the current row

 

In addition, although not required on the nvt printer, the following encoding should be defined at the same time. Both parties of the Telnet connection will not assume that the other party will receive or transmit the following encoding, or has implemented some special action:

Name	Encoding	Description
Bell (BEL)	7	Generates a signal that can be seen or heard (without moving the print head .)
Back space (BS)	8	Move the print header to the left
Horizontal tab (HT)	9	Move the print header to the next position where the horizontal tab is stopped. It still does not specify how each side detects or sets the stop position of such a tab.
Vertical tab (VT)	11	Move the print header to the stop position of the next vertical tab. It still does not specify how each side detects or sets the stop position of such a tab.
Form feed (FF)	12	Move the print head to the top of the next page to keep the print head at the same horizontal position.

No other encoding will cause nvt printing to perform any action.

In the definition, the sequence "cr lf" will cause the nvt print header to be moved to the left of the next line (same as the series "lf Cr ). However, many systems and terminals do not process Cr and LF independently. To simulate their effects, some processing is required. (For example, many terminals do not have lf-independent Cr, but such terminals can use the return key to simulate a cr .) Therefore, the series cr lf must be treated as a separate "new line" and used when they need to be combined. The series "cr nul" must be used when only one separate carriage return key is required; CR characters must be avoided in other scenarios. This rule ensures that the system can make a reasonable choice when detecting a telnet stream with a character followed by a Cr: whether to perform the "line feed" function or multiple unge operations.

Note that both directions (in the default ASCII mode) require "cr lf" or "cr nul" to ensure the symmetry of the nvt mode.

Although in some cases (such as when remote echo and prohibit advanced options work at the same time), it can be considered that the characters are not sent to an actual printer, to ensure consistency, in a data stream, if a Cr is not followed by a lf, the Protocol requires that a NUL be inserted after the CR.

Correspondingly, if the receiver receives a NUL following the Cr from the data stream (explicitly specifying other options without negotiation options ), remove NUL before converting nvt to the local character set.

The nvt keyboard has a combination of keys, keys, or series to generate all 128-grid usaacii encoding. Note that although some nvt printers are useless, nvt keyboards can still be generated.

In addition to these encodings, The nvt Keyboard can also generate the following additional encodings. In addition to the annotations, The nvt keyboard also defines the meanings of these encodings (although not required ).

The actual code of these "characters" is allocated in the Telnet command section, because in a sense, we can think that these encoding is inherent, these encodings can be used even when the data in the data stream is interpreted as belonging to another character set.

Synch

This key allows a user to clear data channels to the other party. Activating this key will result in sending a DM with TCP emergency notification (refer to the command section ). A pair of DM-Emergency notifications has some meanings defined previously.

Break (BRK)

This encoding is provided because, in many current systems, it is a signal outside the usascii set and has local significance. It can be used to indicate that the break or attention key has been pressed. However, it should be noted that it aims to provide 129th encodings to the system that needs it, not the standard representation of IP addresses.

Interrupt process (IP)

The process of terminating an nvt connection. In addition, it is part of the out-of-band signals of other protocols that use Telnet.

Abort output (AO)

Allow the current process to continue running until the end, but do not send its output information to the user. And send a synchronous signal to the user.

Are you there (ayt)

Send visible (printable) information back to nvt to indicate that ayt has been received.

Erase character (EC)

The receiver deletes the last undeleted leading character or "Print position" in the data stream ".

Erase line (EL)

The receiver will delete all content after the last "cr lf" series (but not including this series) of data streams sent by the telnet connection.

These "extra" keys, that is, the nature of the printer format control characters, are, they are a natural extension of the necessary ing process from "nvt" to "local.

Just like the byte 68 (octal 104) in nvt, it can be mapped to any local encoding that represents "uppercase D, the character EC can also be mapped to the local "delete one character" function.

In addition, in an environment without the "vertical line" character, the ing of encoding 124 (octal 174) is arbitrary. If there is no "delete a character" mechanism locally, the El ing to El is arbitrary (or even not mapped ).

Similarly, for the format control characters, if the terminal does have a vertical tabulation key, then the VT ing is obvious, only when the terminal does not have a vertical tabulation key, the role of VT is unpredictable.

8. Telnet command structure

All Telnet commands contain at least one sequence of two bytes: escape characters of "interpret as command" (IAC) and followed by the command code. The command for Option Negotiation is a three-byte sequence, and the third byte is the encoding of the option. The reason for choosing this format is that it can use "Data Space" for a wider range (compared with basic nvt negotiation ). Conflicts between data bytes and reserved command values are greatly reduced, and all these conflicts require complicated and inefficient methods to convert data bytes into streams. With this method, the same data must be sent twice only when IAC is sent as data. The other 255 codes can be transparently transmitted.

The following are all the defined Telnet commands. Note that these codes and code sequences are meaningful only when there is an IAC before.

Name	Code	Meaning
Se	240	End of sub-negotiation Parameters
NOP	241	Null operation
Data mark	242	The data flow of a synchronization signal. This command is followed by a TCP emergency notification.
Break	243	BRK character of nvt
Interrupt Process	244	IP function process interruption
Abort output	245	AO function output interrupted
Are you there	246	Ayt Function
Erase character	247	The EC function deletes characters.
Erase line	248	Delete row with El Function
Go ahead	249	Ga Signal Continues
Sb	250	Indicates that the sub-negotiation of the required options is followed.
Will	251	Indicates that you want to start using or confirm that the specified option is used.
Won't	252	Indicates that the specified option is denied or the specified option is used.
Do	253	Indicates that one party requires the other party to use it, or confirms that you want the other party to use the specified option.
Don't	254	Indicates that one party requires the other party to stop using the service, or confirms that you no longer want the other party to use the specified option.
IAC	255	Data bytes 255

9. Establish a connection

The telnet TCP connection is established between the user port U and the server port L. The server listens to customer requests on a well-known port l used for this type of connection. Because a TPC connection is fully duplex and identified by both ports, the server can respond to many concurrent connections between user ports U and port L.

Port allocation

When the Service (that is, Remote Terminal Access) is used to provide remote users with access to the service host, the Service port allocated by this protocol is 23 (gossip 27 ). That is, L = 23.