?? 00000016.htm
字號:
<?xml version="1.0" encoding="gb2312"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=gb2312"/><title>TELNET turbolinux </title></head><body><center><h1>BBS 水木清華站∶精華區</h1></center><a name="top"></a>發信人: 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 />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 />
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -