Telnet
Telnet protocol is a member of the TCP/IP protocol family and is a standard protocol for Internet remote login services. The purpose of Telnet protocol is to provide a relatively universal, bidirectional, octet-oriented communication method that allows interface terminal devices and terminal-oriented processes to interact with each other through a standard process. The application of Telnet protocol can turn the computer used by the local user into a terminal of the remote host system.
The Telnet protocol has the following characteristics:
Adapt to heterogeneity
In order to make Telnet interoperability between multiple operating systems possible, it is necessary to have a detailed understanding of heterogeneous computers and operating systems. For example, some operating systems require each line of text to end with an ASCII carriage return control character (CR), while others require the use of an ASCII line feed character (LF), and still others require the two-character sequence of carriage return-line feed (CR-LF). For another example, most operating systems provide users with a shortcut key to interrupt program execution, but this shortcut key may be different in each system (some systems use CTRL+C, while others use ESCAPE). If the heterogeneity between systems is not taken into account, then the characters or commands issued locally are likely to be inaccurate or erroneous after being transmitted to a remote location and interpreted by the remote system. Therefore, the Telnet protocol must solve this problem.
In order to adapt to heterogeneous environments, the Telnet protocol defines the transmission method of data and commands on the Internet. This definition is called the Network Virtual Terminal (NVT). Its application process is as follows:
For the sent data: the client software converts the keystrokes and command sequences from the user terminal into NVT format and sends it to the server. The server software converts the received data and commands from NVT format to the format required by the remote system. For the returned data: the remote server converts the data from the format of the remote machine into NVT format, and the local client converts the received NVT format data into the local format.
Send remote command
We know that most operating systems provide various shortcut keys to implement corresponding control commands. When users type these shortcut keys in the local terminal, the local system will execute the corresponding control commands instead of taking these shortcut keys as input. So what does Telnet use to implement remote transmission of control commands?
Telnet also uses NVT to define how to transmit control functions from the client to the server. We know that the USASCII character set includes 95 printable characters and 33 control codes. When the user types ordinary characters locally, NVT will transmit them according to their original meaning; when the user types shortcut keys (combination keys), NVT will convert them into special ASCII characters and transmit them on the network, and convert them into corresponding control commands after they reach the remote machine. There are two main reasons for distinguishing the normal ASCII character set from the control commands:
This distinction means that Telnet has greater flexibility: it can transmit all possible ASCII characters and all control functions between the client and the server; this distinction allows the client to specify signaling unambiguously without confusing control functions with ordinary characters.
Data Flow
Designing Telnet as application-level software has a disadvantage: it is not efficient. Why is this? Here is the data flow in Telnet:
Data information is typed by the user from the local keyboard and transmitted to the client program through the operating system. The client program processes it and returns it to the operating system, which transmits it to the remote machine through the network. The remote operating system transmits the received data to the server program, which is processed again by the server program and returned to the pseudo-terminal entry point on the operating system. Finally, the remote operating system transmits the data to the application program that the user is running. This is a complete input process; the output will be transmitted from the server to the client through the same path.
Because for each input and output, the computer will switch process environments several times, this overhead is very expensive. Fortunately, the user's typing rate is not high, so this disadvantage is still acceptable to us.
Enforcement Order
We should consider the following situation: suppose the local user runs an endlessly looping error command or program on the remote machine, and this command or program has stopped reading input, then the buffer of the operating system may be filled up. If so, the remote server can no longer write data to the pseudo terminal, and eventually stops reading data from the TCP connection. The buffer of the TCP connection will eventually be filled up, thus preventing the flow of data into this connection. If the above situation really happens, the local user will lose control of the remote machine.
To solve this problem, the Telnet protocol must use out-of-band signaling to force the server to read a control command . We know that TCP uses the urgent data mechanism to implement out-of-band data signaling, so Telnet only needs to add a reserved octet called a date mark and notify the server by having TCP send a segment with the urgent data bit set. The segment carrying the urgent data will bypass flow control and reach the server directly. In response to the urgent signaling, the server will read and discard all data until it finds a date mark. The server will return to normal processing after encountering the date mark.
Option Negotiation
Due to the heterogeneity of the machines and operating systems at both ends of Telnet, Telnet cannot and should not strictly stipulate the detailed configuration of each Telnet connection, otherwise it will greatly affect Telnet's adaptability to heterogeneity. Therefore, Telnet uses the option negotiation mechanism to solve this problem.
Telnet options cover a wide range of areas: some options extend the functionality of the general idea, while others control minor details. For example, there is an option that controls whether Telnet operates in half-duplex or full-duplex mode (the general idea); another option allows the server on the remote machine to determine the type of terminal the user is using (the minor details).
The way Telnet negotiates options is also very interesting. It handles each option symmetrically, that is, either end can issue a negotiation request; either end can accept or reject the request. In addition, if one end attempts to negotiate an option that the other end does not understand, the end that accepts the request can simply refuse the negotiation. Therefore, it is possible to interoperate newer, more complex Telnet client and server versions with older, less complex versions. If both the client and server understand the new options, the interaction may be improved. Otherwise, they will both switch to a less efficient but workable mode. All of these designs are to enhance adaptability to heterogeneity, which shows how important Telnet's adaptability to heterogeneity is to its application and development.
The main body of the Telnet protocol consists of three parts:
Definition of Network Virtual Terminal (NVT); Definition of operation negotiation; Negotiation finite automaton;
As the name implies, a Network Virtual Terminal (NVT) is a virtual terminal device used by clients and servers to establish consistency in data representation and interpretation.
Composition of NVT
The network virtual terminal NVT consists of two parts:
Output device: output remote data, usually a display Input device: local data input
Data format transmitted on NVT
The data transmitted on the network virtual terminal NVT uses 8-bit byte data, where the byte with the highest bit of 0 is used for general data and the byte with the highest bit of 1 is used for NVT commands.
Use of NVT in TELNET
TELNET uses a symmetrical data representation. When each client sends data, it maps the character representation of its local terminal to the character representation of NVT. When receiving data, it maps the representation of NVT to the local character set.
At the beginning of communication, both parties support a basic subset of NVT terminal features (which can only distinguish between data and commands) in order to communicate at the lowest level. On this basis, the two parties negotiate NVT commands to determine the higher-level features of NVT and expand the NVT functions.
In TELNET, there are a large number of sub-protocols used to negotiate and expand the functions of the basic network virtual terminal NVT. Due to the diversity of terminal types, the TELNET protocol family has become huge.
2.2.1. Why negotiate operation options?
After the network virtual terminal device is defined, the communicating parties can achieve data communication at a lower level. However, the features of the basic NVT device are very limited. It can only receive and display 7-bit ASCII codes and does not have the most basic editing capabilities. Therefore, a simple NVT device has no practical application significance. For this reason, the TELNET protocol defines a family of protocols to extend the functions of the basic NVT, with the aim of enabling NVT to maximize the functions of the user terminal.
In order to support a variety of terminal features, the TELNET protocol stipulates that a negotiation mechanism should be used when extending the NVT function. Only features that the communicating parties agree on through negotiation can be used and the NVT can be given the feature. This can support the interconnection of terminal devices with different terminal features and ensure that they work within their own capabilities.
2.2.2. Operation Negotiation Command Format
TELNET operation negotiation uses NVT commands, which are byte streams with the highest bit being 1. Each NVT command starts with the byte IAC (0xFF). The principle is as follows:
Whenever a client or server wants to send a command sequence instead of a data stream, it inserts a special reserved character in the data stream. This reserved character is called the "Interpret As Command" (IAC) character. When the receiver finds the IAC character in an incoming data stream, it processes the subsequent bytes as a command sequence. The following is a list of all Telnet NVT commands, which are rarely used.
Table 1 TELNET commands
The commonly used TELNET option negotiations are as follows:
WILL (option code) 251 indicates the option to start execution or confirm the option to operate the instruction. WON'T (option code) 252 indicates the option to refuse to execute or continue the instruction. DO (option code) 253 indicates the option to ask the other party to execute or confirm the option to ask the other party to execute the instruction. DON'T (option code) 254 indicates the option to ask the other party to stop executing or confirm the option to ask the other party to stop executing the instruction. Then there are the following combinations for the receiver and the sender:
Table 2 Six cases of TELNET option negotiation
The sender wants the other party to invalidate an option, and the receiver must accept the request.
Option negotiation requires 3 bytes: IAC, followed by WILL, DO, WONT or DONT; the last identification byte is used to indicate the option of the operation. Commonly used option codes are as follows:
Table 3 TELNET option codes
Normally, the client sends characters to the server and the server echoes them to the user's terminal. However, if network delays cause echoing to be too slow, the user may prefer to have the local system echo the characters. Before the client allows the local system to echo, it sends the following sequence to the server:
IAC DONT ECHO
After receiving the request, the server sends a 3-character response:
IAC WONT ECHO
Indicates that the server has agreed to turn off the echo as requested.
In addition to "on" or "off", some options require more information. For example, to specify the terminal type, the client must send a string to identify the terminal type, so sub-option negotiation must be defined.
RFC 1091 defines the suboption negotiation of terminal type. For example:
The client sends the byte sequence to request that an option be turned on:
<IAC, WILL, 24>
24 is the option identifier for the terminal type. If the server agrees to the request, the response is:
<IAC, DO, 24>
The server then sends
<IAC,SB,24,1,IAC,SE> Requests the client to give its terminal type.
SB is the suboption start command. The next byte 24 indicates that this suboption is a terminal type option. The next byte 1 indicates: Send your terminal type. The client's response is:
<IAC,SB,24,0,'I','B','M','P','C',IAC,SE>
The fourth byte 0 means "my terminal type is".
The entire protocol software is divided into three modules, and the functions of each module are as follows:
Input/output module with local users: handles user input/output;
Input/output module with remote system: handle input/output with remote system;
TELNET protocol module: implements TELNET protocol and maintains the protocol state machine.
The telnet client does two things:
Read the characters typed by the user on the keyboard and send them to the remote server through the TCP connection. Read the characters received from the TCP connection and display them on the user's terminal.
You can add the following code in main.c
Projectspackagesnetutils - v1.3.1 -> telnet -> telnet.c
The main function in the code is void telnet_server(void)
Successfully connected to the telnet server and started running.
Last updated