Internetworking with TCP/IP- P54 docx

Sec. 25.4 Accommodating Heterogeneity 489 Client System format used NVT format used Server System format used user's keyboard & display Figure 25.2 Use of the Network Virtual Terminal (NVT) format by TELNET. The definition of NVT format is fairly straightforward. All communication in- volves 8-bit bytes. At startup, NVT uses the standard 7-bit USASCII representation for data and reserves bytes with the high order bit set for command sequences. The US- ASCII character set includes 95 characters that have "printable" graphics (e.g., letters, digits, and punctuation marks) as well as 33 "control" codes. All printable characters are assigned the same meaning as in the standard USASCII character set. The NVT standard defines interpretations for control characters as shown in Figure 25.3t. / 'I Client ASCII Control Code NUL BEL BS HT LF VT FF CR other control TCP connection across internet Decimal Value No operation (has no effect on output) Sound audibleJvisibIe signal (no motion) Move left one character position Move right to the next horizontal tab stop Move down (vertically) to the next line Move down to the next vertical tab stop Move to the top of the next page Move to the left margin on the current line No operation (has no effect on output) Figure 253 The TELNET NVT interpretation of USASCII control characters. TELNET does not specify the locations of tab stops. In addition to the control character interpretation in Figure 25.3, NVT defines the standard line termination to be a two-character sequence CR-LF. When a user presses the key that corresponds to end-of-line on the local terminal (e.g., ENTER or RETURN), the TELNET client must map it into CR-LF for transmission. The TELNET server translates CR-LF into the appropriate end-of-line character sequence for the remote machine. tThe NVT interpretation of control characters follows the usual ASCII interpretation. 490 Applications: Remote Login (TELNET, Rlogin) Chap. 25 25.5 Passing Commands That Control The Remote Side We said that most systems provide a mechanism that allows users to terminate a running program. Usually, the local operating system binds such mechanisms to a par- ticular key or keystroke sequence. For example, unless the user specifies otherwise, many UNIX systems reserve the character generated by CONTROL-C as the intermpt key. Depressing CONTROL-C causes UNIX to terminate the executing program; the program does not receive CONTROL-C as input. The system may reserve other charac- ters or character sequences for other control functions. TELNET NVT accommodates control functions by defining how they are passed from the client to the server. Conceptually, we think of NVT as accepting input from a keyboard that can generate more than 128 possible characters. We assume the user's keyboard has virtual (imaginary) keys that correspond to the functions typically used to control processing. For example, NVT defines a conceptual "intermpt" key that re- quests program termination. Figure 25.4 lists the control functions that NVT allows. Signal I P A0 An EC EL SYNCH BRK Meaning Interrupt Process (terminate running program) Abort Output (discard any buffered output) Are You There (test if server is responding) Erase Character (delete the previous character) Erase Line (delete the entire current line) Synchronize (clear data path until TCP urgent data point, but do interpret commands) Break (break key or attention signal) Figure 25.4 The control functions TELNET NVT recognizes. Conceptually, the client receives these from a user in addition to normal data, and passes them to the server's system where they must be inter- preted. In practice, most keyboards do not provide extra keys for commands. Instead, in- dividual operating systems or command interpreters have a variety of ways to generate them. We already mentioned the most common technique: binding an individual ASCII character to a control function so when the user presses the key, the operating system takes the appropriate action instead of accepting the character as input. The NVT designers chose to keep commands separate from the normal ASCII character set for two reasons. First, defining the control functions separately means TELNET has greater flexibility. It can transfer all possible ASCII character sequences between client and server as well as all possible control functions. Second, by separating signals from nor- mal data, NVT allows the client to specify signals unambiguously - there is never con- fusion about whether an input character should be treated as data or as a control func- tion. Sec. 25.5 Passing Commands That Control The Remote Side 49 1 To pass control functions across the TCP connection, TELNET encodes them us- ing an escape sequence. An escape sequence uses a reserved octet to indicate that a control code octet follows. In TELNET, the reserved octet that starts an escape se- quence is known as the interpret as command (IAC) octet. Figure 25.5 lists the possible commands and the decimal encoding used for each. Decimal Command Encoding IAC 255 DON'T DO WON'T WILL SB GA EL EC AYT A0 IP BRK DMARK NOP 241 SE 240 EOR 239 Meaning Interpret next octet as command (when the IAC octet appears as data, the sender doubles it and sends the 2octet sequence IAC-IAC) Denial of request to perform specified option Approval to allow specified option Refusal to perform specified option Agreement to perform specified option Start of option subnegotiation The "go ahead" signal The "erase line" signal The "erase character" signal The "are you there" signal The "abort output" signal The "interrupt process" signal The "break" signal The data stream portion of a SYNCH (always accompanied by TCP Urgent notification) No operation End of option subnegotiation End of record Fire 25.5 TELNET commands and encoding for each. The codes only have meaning if preceded by an IAC character. When IAC oc- curs in the data. it is sent twice. As the figure shows, the signals generated by conceptual keys on an NVT key- board each have a corresponding command. For example, to request that the server in- terrupt the executing program, the client must send the 2-octet sequence IAC IP (255 followed by 244). Additional commands allow the client and server to negotiate which options they will use and to synchronize communication. 492 Applications: Remote Login (TEJ NET, Rlogin) Chap. 25 25.6 Forcing The Server To Read A Control Function Sending control functions along with normal data is not always sufficient to guarantee the desired results. To see why, consider the situation under which a user might send the interrupt process control function to the server. Usually, such control is only needed when the program executing on the remote machine is misbehaving and the user wants the server to terminate the program. For example, the program might be ex- ecuting an endless loop without reading input or generating output. Unfortunately, if the application at the server's site stops reading input, operating system buffers will eventually fill and the server will be unable to write more data to the pseudo terminal. When this happens, the server must stop reading data from the TCP connection, causing its buffers to fill. Eventually, TCP on the server machine will begin advertising a zero window size, preventing data from flowing across the connection. If the user generates an interrupt control function when buffers are filled, the con- trol function will never reach the server. That is, the client can form the command se- quence IAC IP and write it to the TCP connection, but because TCP has stopped send- ing to the server's machine, the server will not read the control sequence. The point is: TELNET cannot rely on the conventional data stream alone to carry control sequences between client and server, because a misbehaving application that needs to be controlled might inadvertently block the data stream. To solve the problem, TELNET uses an out of band signal. TCP implements out of band signaling with the urgent data mechanism. Whenever it places a control func- tion in the data stream, TELNET also sends a SYNCH command. TELNET then ap- pends a reserved octet called the data mark, and causes TCP to signal the server by sending a segment with the URGENT DATA bit set. Segments carrying urgent data bypass flow control and reach the server immediately. In response to an urgent signal, the server reads and discards all data until it finds the data mark. The server returns to normal processing when it encounters the data mark. 25.7 TELNET Options Our simple description of TELNET omits one of the most complex aspects: op- tions. In TELNET, options are negotiable, making it possible for the client and server to reconfigure their connection. For example, we said that usually the data stream passes 7-bit data and uses octets with the eighth bit set to pass control information like the Interrupt Process command. However, TELNET also provides an option that al- lows the client and server to pass 8-bit data (when passing 8-bit data, the reserved octet LAC must still be doubled if it appears in the data). The client and server must nego- tiate, and both must agree to pass 8-bit data before such transfers are possible. Sec. 25.7 TELNET Options 493 The range of TELNET options is wide: some extend the capabilities in major ways while others deal with minor details. For example, the original protocol was designed for a half-duplex environment where it was necessary to tell the other end to "go ahead" before it would send more data. One of the options controls whether TELNET operates in half- or full-duplex mode. Another option allows the server on a remote machine to determine the user's terminal type. The terminal type is important for software that generates cursor positioning sequences (e.g., a full screen editor executing on a remote machine). Figure 25.6 lists several of the most commonly implemented TELNET options. Name Transmit Binary Echo Suppress-GA Status Timing-Mark Terminal-Type End-of-Record Linemode Code 0 1 3 RFC 856 857 858 Meaning Change transmission to &bit binary Allow one side to echo data it receives Suppress (no longer send) Go-ahead signal after data Request for status of a TELNET option from remote site Request timing mark be inserted in return stream to synchronize two ends of a connection Exchange information about the make and model of a terminal being used (allows programs to tailor output like cursor positioning sequences for the user's terminal) Terminate data sent with EOR code Use local editing and send complete lines instead of individual characters Figure 25.6 Commonly used TELNET options. 25.8 TELNET Option Negotiation The way TELNET negotiates options is interesting. Because it sometimes makes sense for the server to initiate a particular option, the protocol is designed to allow ei- ther end to make a request. Thus, the protocol is said to be symmetric with respect to option processing. The receiving end either responds to a request with a positive accep- tance or a rejection. In TELNET terminology, the request is WILL X, meaning will you agree to let me use option X; and the response is either DO X or DON'T X, meaning I do agree to let you use option X or I don't agree to let you use option X. The sym- metry arises because DO X requests that the receiving party begin using option X, and WILL X or WON'T X means I will start using option X or I won't start using it?. ?To eliminate potential loops that arise when two sides each think the other's acknowledgement is a re- quest, the protocol specifies that no acknowledgement be given to a request for an option that is already in use. 494 Applications: Remote Login (TELNET, Rlogin) Chap. 25 Another interesting negotiation concept arises because both ends are required to run an unenhanced NVT implementation (i.e., one without any options turned on). If one side tries to negotiate an option that the other does not understand, the side receiv- ing the request can simply decline. Thus, it is possible to interoperate newer, more so- phisticated versions of TELNET clients and servers (i.e., software that understands more options) with older, less sophisticated versions. If both the client and server understand the new options, they may be able to improve interaction. If not, they will revert to a less efficient, but workable style. We can summarize: TELNET uses a symmetric option negotiation mechanism to allow clients and servers to reconfigure the parameters controlling their in- teraction. Because all TELNET sofiware understands a basic NVT protocol, clients and servers can interoperate even if one understands options another does not. 25.9 Rlogin (BSD UNIX) Operating systems derived from BSD UNIX include a remote login service, rlogin, that supports trusted hosts. It allows system administrators to choose a set of machines over which login names and file access protections are shared and to establish equivalences among user logins. Users can control access to their accounts by authoriz- ing remote login based on remote host and remote user name. Thus, it is possible for a user to have login name X on one machine and Y on another, and still be able to re- motely login from one of the machines to the other without typing a password each time. Having automatic authorization makes remote login facilities useful for general purpose programs as well as human interaction. One variant of the rlogin command, rsh, invokes a command interpreter on the remote UNIX machine and passes the com- mand line arguments to the command interpreter, skipping the login step completely. The format of a command invocation using rsh is: rsh machine command on any of the machines in the Computer Science Department at F'urdue University exe- cutes the ps command on machine merlin, with UNIX's standard input and standard output connected across the network to the user's keyboard and display. The user sees the output as if he or she were logged into machine merlin. Because the user can ar- range to have rsh invoke remote commands without prompting for a password, it can be used in programs as well as from the keyboard. Sec. 25.9 Rlogin @SD UNE) 495 Because protocols like rlogin understand both the local and remote computing en- vironments, they communicate better than general purpose remote login protocols like TELNET. For example, rlogin understands the UNIX notions of standard input, stan- dard output, and standard error, and uses TCP to connect them to the remote machine. Thus, it is possible to type and have output from the remote command redirected? into file filename. Rlogin also understands terminal control functions like flow control characters (typically Control-S and Control-Q). It arranges to stop output immediately without waiting for the delay required to send them across the network to the remote host. Finally, rlogin exports part of the user's environment to the remote machine, including information like the user's terminal type (i.e., the TERM variable). As a result, a remote login session ap- pears to behave almost exactly like a local login session. 25.1 0 Summary Much of the rich functionality associated with TCPIIP results from a variety of high-level services supplied by application programs. The high-level remote login pro- tocols these programs use build on the basic services: unreliable datagram delivery and reliable stream transport. The services usually follow the client-server model in which servers operate at known protocol ports so clients know how to contact them. We reviewed two remote login systems: TELNET, the TCPIIP internet standard, and rlogin, a popular protocol used with systems derived from BSD UNIX. TELNET provides a basic service. It allows the client to pass commands such as interrupt pro- cess as well as data to the server. It also permits a client and server to negotiate many options. In contrast to TELNET, rlogin allows system managers and users more flexi- bility in establishing the equivalence of accounts on multiple machines, but it is not as widely available as TELNET. FOR FURTHER STUDY Many high-level protocols have been proposed, but only a few are in common use. Edge 119791 compares end-to-end protocols with the hop-by-hop approach. Saltzer, Reed, and Clark [I9841 argues for having the highest level protocols perform end-to-end acknowledgement and error detection. Postel [RFC 8541 contains the TELNET remote login protocol specification. It was preceded by over three dozen RFCs that discuss TELNET options, weaknesses, ex- periments, and proposed changes, including Postel [RFC 7641 that contains an earlier standard. Postel and Reynolds [RFC 8551 gives a specification for options and consid- tThe "greater than" symbol is the usual UNIX syntax for directing the output of a command into a file. 496 Applications: Remote Login (TELNET, Rlogin) Chap. 25 ers subnegotiation. A lengthy list of options can be found in RFCs 856, 857, 858, 859, 860,861,884,885, 1041, 1091, 1096, 1097, 1184, 1372, 1416, and 1572. The program h3270 uses a TELNET-like mechanism to provide access to IBM computers running the VMICMS operating system [RFCs 1576, 1646 and 16471; Rekhter [RFC 10411 cov- ers the TELNET option that permits communication with IBM 3270 displays. EXERCISES Experiment with both TELNET and rlogin. What are the noticeable differences? Despite the large volume of notes written about TELNET, it can be argued that the pro- tocol is still not well-defined. Experiment with TELNET: use it to reach a machine, A, and invoke TELNET on A to reach a second machine, B. Does the combination of two TELNET connections handle line feed and carriage control characters properly? What is a remote procedure call? Folklore says that operating systems come and go while protocols last forever. Test this axiom by surveying your local computing site to see whether operating systems or com- munication protocols have changed more frequently. Build TELNET client software. Use a TELNET client to connect your keyboard and display to the TCP protocol port for echo or chargen on your local system to see what happens. Read the TELNET standard and find out how the SYNCH operation works. TELNET uses TCP's urgent data mechanism to force the remote operating system to respond to control functions quickly. Read the standard to find out which commands the remote server honors while scanning the input stream. How can the symmetric DODON'T - WILUWON'T option negotiation produce an endless loop of responses if the other party always acknowledges a request? RFC 854 (the TELNET protocol specification) contains exactly 854 lines of text. Do you think there is cosmic significance in this? Applications: File Transfer And Access (FTP, TFTP, NFS) 26.1 Introduction This chapter continues our exploration of application protocols. It examines the file access and transfer protocols that are part of the TCPm protocol suite. It describes their design and shows an example of a typical user interface. We will learn that the most widely used file transfer protocol builds on TCP, covered in Chapter 13, and TEL- NET, described in the previous chapter. 26.2 File Access And Transfer Many network systems provide computers with the ability to access files on remote machines. Designers have explored a variety of approaches to remote access; each ap- proach optimizes for a particular set of goals. For example, some designs use remote file access to lower overall cost. In such architectures, a single, centralizedfile server provides secondary storage for a set of inexpensive computers that have no local disk storage. For example, the diskless machines can be portable, hand-held devices used for chores such as inventory. Such machines communicate with a file server over a high-speed wireless network. 498 Applications: File Transfer And Access (FTP, TITP, NFS) Chap. 26 Some designs use remote storage to archive data. In such designs, users have con- ventional computers with local storage facilities and operate them as usual. Periodically the conventional computers send copies of files (or copies of entire disks) across a net- work to an archival facility, where they are stored in case of accidental loss. Finally, some designs emphasize the ability to share data across multiple programs, multiple users, or multiple sites. For example, an organization might choose to have a single on-line database of outstanding orders shared by all groups in the organization. 26.3 On-line Shared Access File sharing comes in two distinct forms: on-line access and whole-file copying. Shared on-line access means allowing multiple programs to access a single file con- currently. Changes to the file take effect immediately and are available to all programs that access the file. Whole-file copying means that whenever a program wants to access a file, it obtains a local copy. Copying is often used for read-only data, but if the file must be modified, the program makes changes to the local copy and transfers a copy of the modified file back to the original site. Many users think that on-line data sharing can only be provided by a database sys- tem that operates as a server and allows users (clients) to contact it from remote sites. However, file sharing is usually more sophisticated and easier to use. For example, a file system that provides shared, on-line access for remote users does not necessarily re- quire a user to invoke a special client program as a database system does. Instead, the operating system provides access to remote, shared files exactly the same way it pro- vides access to local files. A user can execute any application program using a remote file as input or output. We say that the remote file is integrated with local files, and that the entire file system provides transparent access to shared files. The advantage of transparent access should be obvious: remote file access occurs with no visible changes to application programs. Users can access both local and re- mote files, allowing them to perform arbitrary computations on shared data. The disad- vantages are less obvious. Users may be surprised by the results. For example, consid- er an application program that uses both local and remote files. If the network or the remote machine is down, the application program may not work even though the user's machine is operating. Even if the remote machine is operating, it may be overloaded or the network may be congested, causing the application program to run slowly, or caus- ing communication protocols to report timeout conditions that the user does not expect. The application program seems unreliable. Despite its advantages, implementing integrated, transparent file access can be dif- ficult. In a heterogeneous environment, file names available on one computer may be impossible to map into the file namespace of another. Similarly, a remote file access mechanism must handle notions of ownership, authorization, and access protection, which do not transcend computer system boundaries. Finally, because file representa- tions and allowed operations vary from machine to machine, it may be difficult or im- possible to implement all operations on all files. . request. Thus, the protocol is said to be symmetric with respect to option processing. The receiving end either responds to a request with a positive accep- tance or a rejection. In TELNET. [RFC 10411 cov- ers the TELNET option that permits communication with IBM 3270 displays. EXERCISES Experiment with both TELNET and rlogin. What are the noticeable differences? Despite. integrated with local files, and that the entire file system provides transparent access to shared files. The advantage of transparent access should be obvious: remote file access occurs with