感想

對於這次的專題，我覺得讓我最困擾的倒不是 coding 的部份，而 是英文，我花了不少的時間去研讀規格書，但是始終無法捉住其重點，

幸好還有其他的書籍可以參考，所以才能讓我稍稍有一些概念。

雖然原先的題目並沒有完成，但是我從中學到了很多以前不知道的 用法與技巧，例如：.net 的自訂控制項，其功能就是讓程式設計師可 以開發屬於自己的元件，加入自訂的屬性、事件以及方法，然後就可 以像.net 本身附帶的元件一樣直接拖曳到視窗上就可以使用。我原本 不知道這個用法的時候，WWW 和 BBS 都是混在一起寫的，程式真的亂的 可以，寫到後來真的不知道怎麼繼續下去，但是後來在書上看到這種 用法之後，我把 WWW 和 BBS 分開設計，然後再從主程式呼叫，整個程 式看起來就簡潔明瞭許多了。

1. Andrew Troelsen 原著，陳玄玲譯，用 C#談.NET 平台，旗標，April 2002

2. Anthony Jones and Jim ohlund 原著，黃嘉光譯，C#.NET 網際網 路程式設計-TCP/IP 與 Internet Programming，文魁，May 2003 3. 超維度工作室，Visual Basic .NET Win32 API 大全集，博碩文化，

2003

4. Comer,Douglas E. and David L.Stevens，Internetworking with TCP/IP Vol.Ⅲ:Client-Server Programming and Applications BSD Socket Version 2/E，Prentice Hall，1996

5. 陳弘馨，Microsoft Windows 網路程式設計第二版，Microsoft Press，October 2002

6. 陳永昱 and 黃禎福，Windows 2000 程式設計實務，旗標，September 2000

7. J. Postel and J. Reynolds，RFC 854:TELNET PROTOCOL SPECIFICATION，May 1983

8. Mark Crispin，RFC 727: Telnet Logout Option，April 1977 9. J. Postel and J. Reynolds，RFC 855: TELNET OPTION

SPECIFICATIONS，May 1983

10. J. Postel and J. Reynolds，RFC 857: TELNET ECHO OPTION，May 1983

11. J. VanBokkelen，RFC 1091: Telnet Terminal-Type Option，

February 1989

mnemonic，March 1989

15. http://www.ietf.org/rfc.html，The Internet Engineering Task Force – RFC pages

16. http://www.telnet.org/htm/dev.htm 17. http://vt100.net/

18. http://vt100.net/docs/vt100-ug/

19. http://www.fh-jena.de/~gmueller/Kurs_halle/esc_vt100.html 20. http://www.cmex.org.tw/，中推會

RFC 652 Telnet output carriage-return disposition option RFC 653 Telnet output horizontal tabstops option

RFC 654 Telnet output horizontal tab disposition option RFC 655 Telnet output formfeed disposition option

RFC 656 Telnet output vertical tabstops option

RFC 657 Telnet output vertical tab disposition option RFC 658 Telnet output linefeed disposition

RFC 698 Telnet extended ASCII option

RFC 718 Comments on RCTE from the Tenex implementation experience RFC 719 Discussion on RCTE

RFC 726 Remote Controlled Transmission and Echoing Telnet option RFC 727 Telnet logout option

RFC 728 Minor pitfall in the Telnet Protocol RFC 734 SUPDUP Protocol

RFC 735 Revised Telnet byte macro option RFC 736 Telnet SUPDUP option

RFC 746 SUPDUP graphics extension

RFC 747 Recent extensions to the SUPDUP Protocol RFC 748 Telnet randomly-lose option

RFC 749 Telnet SUPDUP-Output option RFC 779 Telnet send-location option

RFC 857 Telnet echo option

RFC 858 Telnet Suppress Go Ahead option RFC 859 Telnet status option

RFC 860 Telnet timing mark option

RFC 861 Telnet extended options: List option RFC 885 Telnet end of record option

RFC 927 TACACS user identification Telnet option RFC 933 Output marking Telnet option

RFC 946 Telnet terminal location number option RFC 1041 Telnet 3270 regime option

RFC 1043 Telnet Data Entry Terminal option: DODIIS implementation RFC 1053 Telnet X.3 PAD option

RFC 1073 Telnet window size option RFC 1079 Telnet terminal speed option RFC 1091 Telnet terminal-type option

RFC 1096 Telnet X display location option RFC 1097 Telnet subliminal-message option

RFC 1143 The Q Method of Implementing TELNET Option Negotiation RFC 1184 Telnet Linemode option

RFC 1205 5250 Telnet Interface

RFC 1372 Telnet Remote Flow Control Option

RFC 1411 Telnet Authentication: Kerberos Version 4 RFC 1412 Telnet Authentication : SPX

RFC 1416 Telnet Authentication Option

RFC 1576 TN3270 Current Practices

RFC 1646 TN3270 Extensions for LUname and Printer Selection RFC 1647 TN3270 Enhancements

RFC 1921 TNVIP protocol

RFC 2066 TELNET CHARSET Option

RFC 2217 Telnet Com Port Control Option RFC 2840 TELNET KERMIT OPTION

RFC 2877 5250 Telnet Enhancements RFC 2941 Telnet Authentication Option

RFC 2942 Telnet Authentication: Kerberos Version 5 RFC 2943 TELNET Authentication Using DSA

RFC 2944 Telnet Authentication: SRP

RFC 2945 The SRP Authentication and Key Exchange System RFC 2946 Telnet Data Encryption Option

RFC 2947 Telnet Encryption: DES3 64 bit Cipher Feedback RFC 2948 Telnet Encryption: DES3 64 bit Output Feedback RFC 2949 Telnet Encryption: CAST-128 64 bit Output Feedback RFC 2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback RFC 2951 TELNET Authentication Using KEA and SKIPJACK RFC 2952 Telnet Encryption: DES 64 bit Cipher Feedback RFC 2953 Telnet Encryption: DES 64 bit Output Feedback

Request for Comments: 854 J. Reynolds ISI Obsoletes: NIC 18639 May 1983 TELNET PROTOCOL SPECIFICATION

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard.

INTRODUCTION

The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. It is envisioned that the protocol may also be used for terminal-terminal communication ("linking") and process-process communication (distributed computation).

GENERAL CONSIDERATIONS

A TELNET connection is a Transmission Control Protocol (TCP) connection used to transmit data with interspersed TELNET control information.

The TELNET Protocol is built upon three main ideas: first, the concept of a "Network Virtual Terminal"; second, the principle of negotiated options; and third, a symmetric view of terminals and processes.

1. When a TELNET connection is first established, each end is assumed to originate and terminate at a "Network Virtual Terminal", or NVT. An NVT is an imaginary device which provides a standard, network-wide, intermediate representation of a canonical terminal.

This eliminates the need for "server" and "user" hosts to keep information about the characteristics of each other's terminals and terminal handling conventions. All hosts, both user and server, map their local device characteristics and conventions so as to appear to be dealing with an NVT over the network, and each can assume a similar mapping by the other party. The NVT is intended to strike a balance between being overly restricted (not providing hosts a rich enough vocabulary for mapping into their local character sets), and being overly inclusive (penalizing users with modest terminals).

NOTE: The "user" host is the host to which the physical terminal is normally attached, and the "server" host is the host which is normally providing some service. As an alternate point of view,

Postel & Reynolds [Page 1]

communications, the "user" host is the host which initiated the communication.

2. The principle of negotiated options takes cognizance of the fact that many hosts will wish to provide additional services over and above those available within an NVT, and many users will have sophisticated terminals and would like to have elegant, rather than minimal, services. Independent of, but structured within the TELNET Protocol are various "options" that will be sanctioned and may be

used with the "DO, DON'T, WILL, WON'T" structure (discussed below) to allow a user and server to agree to use a more elaborate (or perhaps just different) set of conventions for their TELNET connection. Such options could include changing the character set, the echo mode, etc.

The basic strategy for setting up the use of options is to have either party (or both) initiate a request that some option take effect. The other party may then either accept or reject the request. If the request is accepted the option immediately takes effect; if it is rejected the associated aspect of the connection

remains as specified for an NVT. Clearly, a party may always refuse a request to enable, and must never refuse a request to disable some option since all parties must be prepared to support the NVT.

The syntax of option negotiation has been set up so that if both parties request an option simultaneously, each will see the other's request as the positive acknowledgment of its own.

3. The symmetry of the negotiation syntax can potentially lead to nonterminating acknowledgment loops -- each party seeing the incoming commands not as acknowledgments but as new requests which must be acknowledged. To prevent such loops, the following rules prevail:

a. Parties may only request a change in option status; i.e., a

the transmission of a request and the receipt of an connection is first established, as each party attempts to get the best possible service from the other party. Beyond that, however, options can be used to dynamically modify the characteristics of the connection to suit changing local conditions. For example, the NVT, as will be explained later, uses a transmission discipline well

suited to the many "line at a time" applications such as BASIC, but poorly suited to the many "character at a time" applications such as NLS. A server might elect to devote the extra processor overhead required for a "character at a time" discipline when it was suitable for the local process and would negotiate an appropriate option.

However, rather than then being permanently burdened with the extra processing overhead, it could switch (i.e., negotiate) back to NVT when the detailed control was no longer necessary.

It is possible for requests initiated by processes to stimulate a nonterminating request loop if the process responds to a rejection by merely re-requesting the option. To prevent such loops from occurring, rejected requests should not be repeated until something changes. Operationally, this can mean the process is running a different program, or the user has given another command, or whatever makes sense in the context of the given process and the given option.

A good rule of thumb is that a re-request should only occur as a result of subsequent information from the other end of the connection or when demanded by local human intervention.

Option designers should not feel constrained by the somewhat limited syntax available for option negotiation. The intent of the simple syntax is to make it easy to have options -- since it is

correspondingly easy to profess ignorance about them. If some particular option requires a richer negotiation structure than

possible within "DO, DON'T, WILL, WON'T", the proper tack is to use "DO, DON'T, WILL, WON'T" to establish that both parties understand the option, and once this is accomplished a more exotic syntax can be used freely. For example, a party might send a request to alter (establish) line length. If it is accepted, then a different syntax can be used for actually negotiating the line length -- such a

"sub-negotiation" might include fields for minimum allowable, maximum allowable and desired line lengths. The important concept is that

Postel & Reynolds [Page 3]

(standard) negotiation has established that both parties are capable of parsing the expanded syntax.

In summary, WILL XXX is sent, by either party, to indicate that party's desire (offer) to begin performing option XXX, DO XXX and DON'T XXX being its positive and negative acknowledgments; similarly, DO XXX is sent to indicate a desire (request) that the other party (i.e., the recipient of the DO) begin performing option XXX, WILL XXX and WON'T XXX being the positive and negative acknowledgments. Since the NVT is what is left when no options are enabled, the DON'T and

WON'T responses are guaranteed to leave the connection in a state which both ends can handle. Thus, all hosts may implement their TELNET processes to be totally unaware of options that are not supported, simply returning a rejection to (i.e., refusing) any option request that cannot be understood.

As much as possible, the TELNET protocol has been made server-user symmetrical so that it easily and naturally covers the user-user

(linking) and server-server (cooperating processes) cases. It is hoped, but not absolutely required, that options will further this intent. In any case, it is explicitly acknowledged that symmetry is an operating principle rather than an ironclad rule.

A companion document, "TELNET Option Specifications," should be consulted for information about the procedure for establishing new options.

THE NETWORK VIRTUAL TERMINAL

The Network Virtual Terminal (NVT) is a bi-directional character

device. The NVT has a printer and a keyboard. The printer responds to incoming data and the keyboard produces outgoing data which is sent over the TELNET connection and, if "echoes" are desired, to the NVT's printer as well. "Echoes" will not be expected to traverse the network (although options exist to enable a "remote" echoing mode of operation, no host is required to implement this option). The code

conditions pertain to the transmission of data over the TELNET

generated, and if not returns control to the terminal. If

connection is being used for process-to-process communication, GAs need not be sent in either direction. Finally, for

STANDARD REPRESENTATION OF CONTROL FUNCTIONS

As stated in the Introduction to this document, the primary goal of the TELNET protocol is the provision of a standard interfacing of terminal devices and terminal-oriented processes through the network. Early experiences with this type of interconnection have shown that certain functions are implemented by most servers, but that the methods of invoking these functions differ widely. For a human user who interacts with several server systems, these differences are highly frustrating. TELNET, therefore, defines a standard representation for five of these functions, as described

Postel & Reynolds [Page 6]

required, meanings (with the exception that the Interrupt Process user who transmits the standard representation for the function.

Interrupt Process (IP)

the appropriate way to do this is to transmit the "Synch"

THE TELNET "SYNCH" SIGNAL

Most time-sharing systems provide mechanisms which allow a through the network; the network's flow control mechanisms may cause such a signal to be buffered elsewhere, for example in the user's host.

Postel & Reynolds [Page 8]

introduced. A Synch signal consists of a TCP Urgent notification, coupled with the TELNET command DATA MARK. The Urgent notification, which is not subject to the flow control pertaining to the TELNET connection, is used to invoke special handling of the data stream by the process which receives it. In this mode, the data stream is immediately scanned for "interesting" signals

as defined below, discarding intervening data. The TELNET command DATA MARK (DM) is the synchronizing mark in the data stream which

"Interesting" signals are defined to be: the TELNET standard representations of IP, AO, and AYT (but not EC or EL); the local analogs of these standard representations (if any); all other

TELNET commands; other site-defined signals which can be acted on without delaying the scan of the data stream.

Since one effect of the SYNCH mechanism is the discarding of essentially all characters (except TELNET commands) between the sender of the Synch and its recipient, this mechanism is specified as the standard way to clear the data path when that is desired.

For example, if a user at a terminal causes an AO to be

transmitted, the server which receives the AO (if it provides that function at all) should return a Synch to the user.

signal. For example, suppose that some other protocol, which uses TELNET, defines the character string STOP analogously to the TELNET command AO. Imagine that a user of this protocol wishes a server to process the STOP string, but the connection is blocked because the server is processing other commands. The user should instruct his system to: and can produce representations of all 95 USASCII graphics (codes 32 through 126). Of the 33 USASCII control codes (0 through 31

required, effects on the NVT printer. Neither end of a TELNET

NVT model. Even though it may be known in some situations options negotiations which explicitly specify otherwise) should be stripped out prior to applying the NVT to local character

Allow the current process to (appear to) run to completion, but effectors, is that they should represent a natural extension of the mapping that already must be done from "NVT" into "local".

Just as the NVT data byte 68 (104 octal) should be mapped into whatever the local code for "uppercase D" is, so the EC character should be mapped into whatever the local "Erase Character"

function is. Further, just as the mapping for 124 (174 octal) is somewhat arbitrary in an environment that has no "vertical bar"

character, the EL character may have a somewhat arbitrary mapping (or none at all) if there is no local "Erase Line" facility.

Similarly for format effectors: if the terminal actually does have a "Vertical Tab", then the mapping for VT is obvious, and only when the terminal does not have a vertical tab should the effect of VT be unpredictable.

TELNET COMMAND STRUCTURE

All TELNET commands consist of at least a two byte sequence: the "Interpret as Command" (IAC) escape character followed by the code for the command. The commands dealing with option negotiation are three byte sequences, the third byte being the code for the option

referenced. This format was chosen so that as more comprehensive use of the "data space" is made -- by negotiations from the basic NVT, of course -- collisions of data bytes with reserved command values will be minimized, all such collisions requiring the inconvenience, and

Postel & Reynolds [Page 13]

current set-up, only the IAC need be doubled to be sent as data, and the other 255 codes may be passed transparently.

The following are the defined TELNET commands. Note that these codes and code sequences have the indicated meaning only when immediately preceded by an IAC.

The TELNET TCP connection is established between the user's port U and the server's port L. The server listens on its well known port L for such connections. Since a TCP connection is full duplex and identified by the pair of ports, the server can engage in many simultaneous connections involving its port L and different user ports U.

Port Assignment

When used for remote user access to service hosts (i.e., remote terminal access) this protocol is assigned server port 23

(27 octal). That is L=23.

Postel & Reynolds [Page 15]