Telnet protocol specifications ....

General considerations

A telnet connection is used to transmit data through the transmission control protocol. The telnet protocol is based on the following three ideas: first, the concept of the network virtual terminal, second, the method of dialogue options, and finally the coordination of terminals and processing.

　

When a telnet connection is established for the first time, each end is assumed to use a network virtual terminal, that is, nvt. Nvt is a typical device for standard devices. This eliminates the need for "servers" and "users" machines to understand the characteristics of their terminals, and terminals can directly process conversations. All Hosts, clients, and servers have their own local device features, so they can be processed as nvt on the network, any device can be considered to be using the same features. Nvt tends to be limited in many ways (it provides a rich set of character sets mapped to local devices), not everything (it requires users to use the appropriate terminal ). Note: A User Machine is usually a host connected to a processing terminal, and a server machine is usually a machine that provides certain services. From another point of view, the user machine is the machine that initiates communication from the terminal to the terminal or process to the process.
The principle of the specified option takes into account the following facts. Many machines want to provide additional services on the current nvt. Most users have complicated terminals, they also want a relatively complete, not minimal service. Independent, but different options in the telnet protocol support these requirements. They use "do, don't, Will, the won't structure allows the user to establish a more sophisticated Telnet session connection with the server. This option includes changing the character set and response mode. The basic policy for setting options is the request that either party (or both) initialize to require an option to take effect. The other party can accept or reject this request. If the request is accepted, this option takes effect immediately. If the request is rejected, the connection still maintains the basic nvt connection attribute. Obviously, one party can reject the other party's request to enable a certain option, but it cannot reject the other party's request to invalidate the option because both parties must prepare to support nvt. When both parties send a request for an option to take effect, the other party may directly consider that the other party has received the confirmation message from the other party.
This symmetric dialog syntax may lead to an irrevocable confirmation ring-any Party regards the confirmation received as a request rather than a confirmation message. To prevent such loops from occurring, there are the following rules:
Either party can only change the status of the option. For example, one party cannot send a request, but only describes the status of the option.
If one party receives the request information, the request enters a status, which is considered as a confirmation message. This kind of non-response essentially prevents the loop of non-terminating conversations. If you want to send a request to change the status, even if the status does not change.
At any time, either party sends the option command to the other party, whether as a request or a confirmation message, the use of the option will have an impact on the Data Processing sent, in this way, the command should be inserted before the data point in the data stream that you want to act on. (Note that there is a certain interval between sending a request and receiving a confirmation message, which is passive. Therefore, a host wants to cache data after asking for an option until it knows whether its request is accepted, so that this period of uncertain time is invisible to users .) Option requests can be exchanged frequently when establishing a telnet connection, because each Party wants to get better services from the other party.
In addition, the options can be dynamically changed during connection continuity to adapt to changes in local machine conditions. For example, nvt (which will be explained in detail later) is applicable to many "one-row" applications, such as basic, but it is not very useful for NLS applications such as "one word at a time. The server may be selected as a "one-word" rule to adapt to the local process running on it. It will initiate a conversation to achieve the appropriate option status. However, compared to being permanently responsible for this extra processing burden, it can return to the nvt state without such an option through session. A request initiated by a process can lead to an irrevocable request loop. If the process responds to a request rejection, this option is requested again. In order to prevent such loops, rejected requests cannot be repeatedly requested until other things change. This may mean that the process runs another program, the user sends another command, or the user changes the environment or options.

A better way is to use a pre-request as the result of sending information from the other end, or because of human intervention. The designer of the option should not feel unable to stretch out due to various restrictions on the option session. The general purpose of syntax is to have options more easily-because it is easy to ignore them.

If the specific options require a richer structure except "do, don't, will, won't", the correct policy is to use "do, don't, Will, won't "to establish a connection to interpret this new structure, which can be freely used when this interpretation is completed. For example, one party may send a request to change (or establish) the length of each line. If you accept this, you can use different syntaxes to indicate the length of different rows of a dialog. A subdialog can contain a field to indicate the maximum allowed, minimum allowed, and expected length. The important concept is that such an extended session should be performed after both parties establish a standard session and can interpret this extended syntax. In general, when sending will xxx, the party wants to execute the options XXX, do XXX and don't XXX as the uncertain response. Similarly, do XXX is sent to the other party as a request to start the options XXX. Will XXX and won t will be responded as a definite and uncertain response. Because nvt is the result without any options, the don't and won't responses ensure that the connection is eventually maintained in this state without any options. Therefore, all hosts do not support incomprehensible options. They only need to return requests for such options.

As far as possible, the Telnet protocol is used as the server-user symmetry so that it can easily and naturally process user-user and server-server situations. Using options to extend this function is expected to be implemented, but not necessary. In any case, symmetry is a running principle rather than a fixed principle that has been explicitly proposed multiple times. A comparison document, "Telnet Option description", can be used as a reference for creating new option process information.

Network virtual terminal (nvt) is a bidirectional character device. Nvt has a display device and a keyboard. Display the data that the device responds to. the keyboard is responsible for sending data through the telnet connection. to display the data back, it should also be displayed on the nvt display device. The Network ECHO is not required (although the "remote" Echo option exists, the host does not have to implement this option ). The character set is composed of seven ASCII codes, which are saved in the eight-bit domain. Any character conversion and timing considerations are local issues, which does not affect nvt.

In terms of data transmission, although the telnet connection is full-duplex, nvt is a half-duplex device in the online buffer status. Although Telnet connections are full-duplex, nvt is used as a half-duplex device in online buffer mode. This signal can be generated by processes or users. For some hosts that process network input interruptions or do not remotely echo nvt by default, the cost of this rule is high. Therefore, there is a reason to cache some data at the source point. Some systems do not use some operations on each input line (this method is often used even for a row printer or a punching machine), so that the transmission can not start on each line. On the other hand, users or processes can sometimes find that providing data without interruption is useful and necessary. Therefore, it is also necessary to implement methods and mechanisms for identifying such signals locally and sending the data immediately. When a process has completed sending data to the display device of the other party and no cached input data, the process must send the Telnet go ahead (GA) command.

This rule does not require the Telnet ga command to be sent by both terminals, because the server host usually does not require a specific signal to continue the process. However, the design of this command can help the user's local host operate on a physical half-duplex terminal, which has a lockable keyboard like ibm2741. The description of this type of terminal helps to explain the correct use of the GA command. The connection between a terminal and a computer is always under the control of a computer or a user. Neither party can obtain control from the other party implicitly; control must be explicitly transferred from one party to the other.

On the terminal side, set the hardware to give up control at the end of each line (for example, when the user presses the Enter key ). In this case, the local computer processes the input data and determines whether to output the data. If not, the control is sent back to the terminal. If output is to be generated, the computer reserves control until the output data is sent. The difficulty of using such a terminal on the network is obvious. "Local" computers do not know whether to maintain control when the reading row is unsigned; the decision on this issue is far from the computer that processes the data. Therefore, the Telnet ga command provides a mechanism for remote computers to notify local computers and send control to user terminals. When the user needs control, this signal should also be sent only at this time. Note: sending the GA command too early will block the output data, because you can assume that the transfer system is suspended, so you cannot end a row. Of course, the aforementioned content cannot be used for user-to-server communication. In this regard, the GA command can be sent at any time without sending at all. Similarly, if the telnet connection is used for process-to-process communication, you do not need to send the GA command.

Finally, for the communication between the terminal and the terminal, Ga commands can be required at both ends, either at one end or both ends. If the host wants to support terminal-to-terminal communication hosts, it should provide a method for users to freely send ga commands. However, this is not necessary for a Telnet process. Note: the symmetry of the Telnet mode requires at least one nvt at one end of the two ends. Standard representation of control functions as described in this article, the Telnet protocol aims to provide a standard interface for terminal processes and devices on the network.

Previous experiences with this type of interconnection tell us that similar functions have been implemented on many hosts, but their implementation methods are quite different. These differences can be a headache for users who are exposed to these systems. Therefore, Telnet defines five standard representations of the following features. This standard expression has a certain standard meaning, but this is not necessary (except that the interrupt processing function needs to be executed by other protocols using telnet); that is to say, the system does not provide functions to local users or remote users. It can use standard representations as non-operational functions.

On the other hand, systems that provide this feature to local users must also provide this feature to remote users that transmit the standard representation of this feature.

Interrupt Processing (IP) Some systems provide the ability to pause, interrupt, or stop user process operations. This function is often used when the user determines that the process is in an endless loop or inadvertently activates a process. IP is the standard representation of this function. Note that IP addresses are also required for other Telnet protocols. Many of the output (AO) systems provide this function, which allows the process that generates the output to reach a point similar to the end of the operation, rather than sending the output to the user's terminal. In a deeper layer, this function usually clears all generated outputs and does not display them on the user's terminal. AO is the standard representation of this function.

For example, some subsystems may usually accept user commands, send long texts to the user terminal, and finally send a prompt prompting the user to allow receiving the next command to the user terminal. If the AO command is received during the process of transmitting a text string, the remaining strings are no longer sent, and the prompt is displayed to inform you that you can enter the next command. (This may be different from the operation after the IP address is received; the IP address will discard the remaining string and exit the subsystem .) It should be noted that the external buffer (on the network and on the user's local host) is also cleared when the server system that provides this function is used; the correct method to do so is to send a "synch" signal to the user system.

You are here (ayt) Many systems provide users with such features to let users know whether they are running. This function is initiated by the user when the system does not respond for a long time due to unpredictable length calculation or heavy system load. Ayt is the standard representation of this feature.

Many systems provide this function to delete recently adjacent non-deletable characters or the nearest adjacent "display location" of user-provided data streams ". This function is usually used to edit incorrect input on the keyboard. EC is the standard representation of this feature. Note: The "display position" may contain more than one character, which is the result of too much input or a string in the following format: <char1> BS <char2>...

Delete row (EL) Many systems provide this function to delete all data in the current input row. This function is usually used to edit keyboard input. El is a standard representation of this feature.

In most cases, the system provides a mechanism that allows end users to re-obtain out-of-control processes when the Telnet "synch" signal is sent. The preceding IP address and AO function are examples of this mechanism. These systems access all signals provided by users when used locally, whether the signal is a common character or a non-printable character, such as the "break" in the telex or the "Attn" key in IBM 2741. This is not always accurate when the system is connected over the network. The network traffic control mechanism may cause a signal to be cached somewhere in the network, for example, in the user's host. To overcome this problem, the "synch" mechanism of telnet is introduced. A synch signal includes a TCP emergency signal and a Telnet command data mark.

Emergency signal, which is not restricted by traffic control of Telnet. It can cause specific data processing when receiving a process.

In this mode, this data stream is immediately seen as "significant" and other data is discarded.

The Telnet command data mark (DM) is the synchronization mark in the data stream. It indicates that any specific signal has already occurred and the received data can be returned to the normal state of processing other data. Synch is sent over TCP. It is sent together with the emergency mark and the last DM mark. Emergency signals may be drowned when some synch signals are continuously and rapidly sent. It is impossible to count emergency signals, because this number may be smaller than or equal to the number already sent. In normal mode, DM is not an operation; in an emergency model, it indicates the end of the emergency process. If the TCP indicates that DM is found before the end of the emergency data, telnet should continue to operate the data stream until DM is encountered. If TCP indicates that there is some urgent data after DM, it is only because it is a string of synch. Telnet should continue to operate the data stream until DM is encountered.

"Meaningful" signals are defined as Telnet standard definitions for IP, AO, and ayt (but not EC or El); if so, local simulation of these standard definitions; all other Telnet commands. signals defined by other sites that do not need to drag data streams. The other role of the synch command is to discard all characters that are not included in the Telnet command between the receiver and the sender. If necessary, this mechanism is specified as a standard method to clean up the data path. For example, if a terminal user transfers an AO command, the server that receives the command (if the server provides this function) should return a synch to the user.

Finally, similar commands are required for other protocols that use the Telnet protocol, just as TCP emergency signals are needed for their use. This can be achieved by using [IP, synch. For example, assume that some other protocols that use Telnet define the stop string of the AO command. Imagine that the user of this Protocol wants the server to process the stop string, but the connection is blocked because the server is processing other commands. The user should make its system do the above work:

Send Telnet IP characters;
Send the Telnet sync string, that is, the send DM is the unique string in TCP emergency mode.
Send the string stop and
Send Telnet DM commands for other protocols.
The user (or process) must resend the Telnet synch sequence like step 2 to ensure that the Telnet IP address reaches the Telnet interpreter on the server. "Urgent" will wake up the Telnet process; IP should wake up more advanced processes. The nvt display and the keyboard nvt display have an unspecified line width and page size, and can generate characters representing ASCII codes.

For 33 control characters and 128 other unused characters, it is specified to display:

NULL (NUL) 0 no operation;

Line feed (LF) 10 will be displayed to the same vertical position in the next row.

Carriage Return (CR) 13 is displayed at the left boundary of the current row.

In addition, the following characters should be defined (but this is not necessary), and they also play a role in display. Neither party of Telnet assumes that the other party will take the following actions during receiving or transmitting:

Bell (BEL) 7 rings or gives a visual signal (this does not move the display position ).

Back space (BS) 8 is displayed to move to the left position.

Horizontal tab (HT) 9 is displayed to the next tab. No one has yet specified how to determine where the position of the primary table is located.

Horizontal tab (HT) 9 moves to the next vertical tab. No one has yet specified how to determine where the position of the primary table is located.

Form feed (FF) 12 displays the starting position of the next page and maintains the same horizontal position. All current Code does not display nvt for any operation.

The cr lf sequence is located at the left boundary of the next row. However, many systems and terminals do not separate these two characters and have to do some work to simulate their functions. (For example, some terminals do not have cr independent from lf, but on these terminals, the CR function can be simulated through the back key .) Therefore, cr lf sequences are bound to use their compound functions as new line markers; cr nul must be used when you want to enter only one carriage return; otherwise, Cr alone should be avoided. This rule allows the system that must decide whether to perform a "new line" operation or multiple rollback operations to ensure that the Telnet stream operation after a single character is followed by a Cr is included and the correct decision is made. Note: cr lf or Cr NUL requires both parties, which ensures the symmetry of nvt. Even if the characters are not sent to the actual terminal in some cases, for consistency reasons, the Protocol requires that a NUL be inserted after CR without lf. Conversely, after receiving a NUL after CR, it should be discarded from the data stream instead of used for nvt character ing.

The nvt has a keyboard, a combination of keys, or a sequence of keys to generate all 128 characters. Note: although some of them have no effect on nvt display, nvt can also generate them. In addition, the nvt keyboard should generate the following characters that are meaningful but not required. The actual code for these characters is assigned in the Telnet command section because they are provided as common characters, even if the data stream is interpreted as some other character sets.

Synch this key allows the user to clear data channels to the other party. The activation of this key causes DM transmission and also causes TCP emergency signals to be sent at the same time. The meaning of DM-emergency signals is as defined previously.

Break (BRK) is provided because it is not a member of the ASCII character set. It indicates that the break key and the attention key are pressed. However, please note that it is defined as 129th Codes instead of IP standard.

Interrupt process (IP) pause, interrupt, discard or terminate the execution of nvt connection processes. Similarly, it is the signal used by the Telnet protocol.

Abort output (AO) allows the current process to run until it is terminated, but does not send the result to the user. Similarly, send synch to the user.

Are you there (ayt) back to nvt some visible characters.

The erase character (EC) receiver should delete the last undeleted character or delete a "display location" from the data stream ".

The erase line (EL) receiver should delete the characters in the data stream from the current position until the latest "cr lf.

These "extra" keys and some display format function keys indicate an extension of the ing from nvt to the local machine. Just as nvt Data byte 68 should be mapped to uppercase D, an EC character should be mapped to a function key for "deleting rows. In addition, if ing 124 is arbitrary in some cases, the El character ing is sometimes arbitrary. The format character is the same: If the terminal actually has a vertical tab, it is obvious to map to nvt. If the terminal does not provide this function, the result will be unpredictable. Telnet command structure all Telnet command structures contain at least one sequence of two bytes: One IAC followed by one command. The option session command is composed of three bytes, and the third byte is about the option reference. Select this structure, and the conflict between the space data and the command value will be reduced. All these conflicts lead to inconsistency and inefficiency and data loss. According to the current settings, only data conflicting with IAC needs to be sent twice, and the other 255 codes can be sent directly. The Telnet command is defined below. Note: It is a command only when the code is IAC before the code sequence.

Se 240 end sub-session parameters.

No operation is performed on NOP 241.

Data mark 242 synch data flow section. This should be sent together with the TCP emergency sign.

Break 243 nvt character BRK.

Interrupt process 244 IP address.

Abort output 245 AO function.

Are You There 246 ayt function.

Erase character 247 EC feature.

Erase character 247 El function.

Go ahead 249 the GA signal.

SB 250 indicates that the following is the subdialog of the indication option.

Will (Option Code) 251 indicates the option that you want to start execution, or confirm that the operation is currently being performed.

Won't (Option Code) 252 indicates the option to refuse to execute or continue the reception instruction.

Do (Option Code) 253 indicates that the other party is required to execute or confirm the option that the other party wants to execute the instruction.

Don't (Option Code) 254 indicates the option to require the recipient to stop the execution, or the diagnosis requires the recipient to stop the execution.

IAC 255 Data byte 255.

　

　

Establish a connection

The telnet TCP connection is established between the user port U and the server port L. The server waits for the connection on this recognized port. Because the TCP connection is a full-duplex, the two ports jointly confirm that the server can simultaneously process many connections from different U ports at the same time on the L port. When the port is used to remotely access the service host, this Protocol specifies port 23 (that is, port 27 of gossip ). That is L = 23