📄 418.htm
字号:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>CTerm非常精华下载</title>
</head>
<body bgcolor="#FFFFFF">
<table border="0" width="100%" cellspacing="0" cellpadding="0" height="577">
<tr><td width="32%" rowspan="3" height="123"><img src="DDl_back.jpg" width="300" height="129" alt="DDl_back.jpg"></td><td width="30%" background="DDl_back2.jpg" height="35"><p align="center"><a href="http://202.112.58.200"><font face="黑体"><big><big>Tsinghua</big></big></font></a></td></tr>
<tr>
<td width="68%" background="DDl_back2.jpg" height="44"><big><big><font face="黑体"><p align="center"> 嵌入式系统 (BM: turbolinux jacobw) </font></big></big></td></tr>
<tr>
<td width="68%" height="44" bgcolor="#000000"><font face="黑体"><big><big><p align="center"></big></big><a href="http://cterm.163.net"><img src="banner.gif" width="400" height="60" alt="banner.gif"border="0"></a></font></td>
</tr>
<tr><td width="100%" colspan="2" height="100" align="center" valign="top"><br><p align="center">[<a href="嵌入式系统.htm">回到开始</a>][<a href="398.htm">上一层</a>][<a href="419.htm">下一篇</a>]
<hr><p align="left"><small>发信人: hellow (收复台湾是我心), 信区: Embedded <br>
标 题: TELNET <br>
发信站: BBS 水木清华站 (Sun Nov 5 09:30:40 2000) <br>
<br>
Network Working Group J. Postel <br>
Request for Comments: 854 J. Reynolds <br>
ISI <br>
Obsoletes: NIC 18639 May 1983 <br>
TELNET PROTOCOL SPECIFICATION <br>
This RFC specifies a standard for the ARPA Internet community. Hosts on <br>
the ARPA Internet are expected to adopt and implement this standard. <br>
INTRODUCTION <br>
The purpose of the TELNET Protocol is to provide a fairly general, <br>
bi-directional, eight-bit byte oriented communications facility. Its <br>
primary goal is to allow a standard method of interfacing terminal <br>
devices and terminal-oriented processes to each other. It is <br>
envisioned that the protocol may also be used for terminal-terminal <br>
communication ("linking") and process-process communication <br>
(distributed computation). <br>
GENERAL CONSIDERATIONS <br>
A TELNET connection is a Transmission Control Protocol (TCP) <br>
connection used to transmit data with interspersed TELNET control <br>
information. <br>
The TELNET Protocol is built upon three main ideas: first, the <br>
concept of a "Network Virtual Terminal"; second, the principle of <br>
negotiated options; and third, a symmetric view of terminals and <br>
processes. <br>
1. When a TELNET connection is first established, each end is <br>
assumed to originate and terminate at a "Network Virtual Terminal", <br>
or NVT. An NVT is an imaginary device which provides a standard, <br>
network-wide, intermediate representation of a canonical terminal. <br>
This eliminates the need for "server" and "user" hosts to keep <br>
information about the characteristics of each other's terminals and <br>
terminal handling conventions. All hosts, both user and server, map <br>
their local device characteristics and conventions so as to appear to <br>
be dealing with an NVT over the network, and each can assume a <br>
similar mapping by the other party. The NVT is intended to strike a <br>
balance between being overly restricted (not providing hosts a rich <br>
enough vocabulary for mapping into their local character sets), and <br>
being overly inclusive (penalizing users with modest terminals). <br>
NOTE: The "user" host is the host to which the physical terminal <br>
is normally attached, and the "server" host is the host which is <br>
normally providing some service. As an alternate point of view, <br>
Postel & Reynolds [Page 1] <br>
<br>
<br>
RFC 854 May 1983 <br>
applicable even in terminal-to-terminal or process-to-process <br>
communications, the "user" host is the host which initiated the <br>
communication. <br>
2. The principle of negotiated options takes cognizance of the fact <br>
that many hosts will wish to provide additional services over and <br>
above those available within an NVT, and many users will have <br>
sophisticated terminals and would like to have elegant, rather than <br>
minimal, services. Independent of, but structured within the TELNET <br>
Protocol are various "options" that will be sanctioned and may be <br>
used with the "DO, DON'T, WILL, WON'T" structure (discussed below) to <br>
allow a user and server to agree to use a more elaborate (or perhaps <br>
just different) set of conventions for their TELNET connection. Such <br>
options could include changing the character set, the echo mode, etc. <br>
The basic strategy for setting up the use of options is to have <br>
either party (or both) initiate a request that some option take <br>
effect. The other party may then either accept or reject the <br>
request. If the request is accepted the option immediately takes <br>
effect; if it is rejected the associated aspect of the connection <br>
remains as specified for an NVT. Clearly, a party may always refuse <br>
a request to enable, and must never refuse a request to disable some <br>
option since all parties must be prepared to support the NVT. <br>
The syntax of option negotiation has been set up so that if both <br>
parties request an option simultaneously, each will see the other's <br>
request as the positive acknowledgment of its own. <br>
3. The symmetry of the negotiation syntax can potentially lead to <br>
nonterminating acknowledgment loops -- each party seeing the incoming <br>
commands not as acknowledgments but as new requests which must be <br>
acknowledged. To prevent such loops, the following rules prevail: <br>
a. Parties may only request a change in option status; i.e., a <br>
party may not send out a "request" merely to announce what mode it <br>
is in. <br>
b. If a party receives what appears to be a request to enter some <br>
mode it is already in, the request should not be acknowledged. <br>
This non-response is essential to prevent endless loops in the <br>
negotiation. It is required that a response be sent to requests <br>
for a change of mode -- even if the mode is not changed. <br>
c. Whenever one party sends an option command to a second party, <br>
whether as a request or an acknowledgment, and use of the option <br>
will have any effect on the processing of the data being sent from <br>
the first party to the second, then the command must be inserted <br>
in the data stream at the point where it is desired that it take <br>
Postel & Reynolds [Page 2] <br>
<br>
<br>
RFC 854 May 1983 <br>
effect. (It should be noted that some time will elapse between <br>
the transmission of a request and the receipt of an <br>
acknowledgment, which may be negative. Thus, a host may wish to <br>
buffer data, after requesting an option, until it learns whether <br>
the request is accepted or rejected, in order to hide the <br>
"uncertainty period" from the user.) <br>
Option requests are likely to flurry back and forth when a TELNET <br>
connection is first established, as each party attempts to get the <br>
best possible service from the other party. Beyond that, however, <br>
options can be used to dynamically modify the characteristics of the <br>
connection to suit changing local conditions. For example, the NVT, <br>
as will be explained later, uses a transmission discipline well <br>
suited to the many "line at a time" applications such as BASIC, but <br>
poorly suited to the many "character at a time" applications such as <br>
NLS. A server might elect to devote the extra processor overhead <br>
required for a "character at a time" discipline when it was suitable <br>
for the local process and would negotiate an appropriate option. <br>
However, rather than then being permanently burdened with the extra <br>
processing overhead, it could switch (i.e., negotiate) back to NVT <br>
when the detailed control was no longer necessary. <br>
It is possible for requests initiated by processes to stimulate a <br>
nonterminating request loop if the process responds to a rejection by <br>
merely re-requesting the option. To prevent such loops from <br>
occurring, rejected requests should not be repeated until something <br>
changes. Operationally, this can mean the process is running a <br>
different program, or the user has given another command, or whatever <br>
makes sense in the context of the given process and the given option. <br>
A good rule of thumb is that a re-request should only occur as a <br>
result of subsequent information from the other end of the connection <br>
or when demanded by local human intervention. <br>
Option designers should not feel constrained by the somewhat limited <br>
syntax available for option negotiation. The intent of the simple <br>
syntax is to make it easy to have options -- since it is <br>
correspondingly easy to profess ignorance about them. If some <br>
particular option requires a richer negotiation structure than <br>
possible within "DO, DON'T, WILL, WON'T", the proper tack is to use <br>
"DO, DON'T, WILL, WON'T" to establish that both parties understand <br>
the option, and once this is accomplished a more exotic syntax can be <br>
used freely. For example, a party might send a request to alter <br>
(establish) line length. If it is accepted, then a different syntax <br>
can be used for actually negotiating the line length -- such a <br>
"sub-negotiation" might include fields for minimum allowable, maximum <br>
allowable and desired line lengths. The important concept is that <br>
Postel & Reynolds [Page 3] <br>
<br>
RFC 854 May 1983 <br>
such expanded negotiations should never begin until some prior <br>
(standard) negotiation has established that both parties are capable <br>
of parsing the expanded syntax. <br>
In summary, WILL XXX is sent, by either party, to indicate that <br>
party's desire (offer) to begin performing option XXX, DO XXX and <br>
DON'T XXX being its positive and negative acknowledgments; similarly, <br>
DO XXX is sent to indicate a desire (request) that the other party <br>
(i.e., the recipient of the DO) begin performing option XXX, WILL XXX <br>
and WON'T XXX being the positive and negative acknowledgments. Since <br>
the NVT is what is left when no options are enabled, the DON'T and <br>
WON'T responses are guaranteed to leave the connection in a state <br>
which both ends can handle. Thus, all hosts may implement their <br>
TELNET processes to be totally unaware of options that are not <br>
supported, simply returning a rejection to (i.e., refusing) any <br>
option request that cannot be understood. <br>
As much as possible, the TELNET protocol has been made server-user <br>
symmetrical so that it easily and naturally covers the user-user <br>
(linking) and server-server (cooperating processes) cases. It is <br>
hoped, but not absolutely required, that options will further this <br>
intent. In any case, it is explicitly acknowledged that symmetry is <br>
an operating principle rather than an ironclad rule. <br>
A companion document, "TELNET Option Specifications," should be <br>
consulted for information about the procedure for establishing new <br>
options. <br>
THE NETWORK VIRTUAL TERMINAL <br>
The Network Virtual Terminal (NVT) is a bi-directional character <br>
device. The NVT has a printer and a keyboard. The printer responds <br>
to incoming data and the keyboard produces outgoing data which is <br>
sent over the TELNET connection and, if "echoes" are desired, to the <br>
NVT's printer as well. "Echoes" will not be expected to traverse the <br>
network (although options exist to enable a "remote" echoing mode of <br>
operation, no host is required to implement this option). The code <br>
set is seven-bit USASCII in an eight-bit field, except as modified <br>
herein. Any code conversion and timing considerations are local <br>
problems and do not affect the NVT. <br>
TRANSMISSION OF DATA <br>
Although a TELNET connection through the network is intrinsically <br>
full duplex, the NVT is to be viewed as a half-duplex device <br>
operating in a line-buffered mode. That is, unless and until <br>
Postel & Reynolds [Page 4] <br>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -