Browse Prior Art Database

Mechanism for Selective 5250 Architecture Bypass of Telnet Protocol Command and Escape Byte Processing

IP.com Disclosure Number: IPCOM000016072D
Original Publication Date: 2002-Jul-28
Included in the Prior Art Database: 2003-Jun-21
Document File: 3 page(s) / 49K

Publishing Venue

IBM

Abstract

In a TCP/IP network that uses a Telnet client/server protocol, applications running on a Telnet server platform may exchange data over a Telnet session connection to applications running on a Telnet client platform. In addition to applications passing data over this Telnet session connection, the Telnet server and client may also pass Telnet Protocol commands over the same session connection. The exchange of application data and Telnet commands adhere to the rules defined in Request For Comments (RFC) 854, which can be found at the Internet Engineering Task Force (IETF) web site as http://www.ietf.org/rfc/rfc854.txt It should be noted that Telnet protocol commands are asynchronous, and may occur in the middle of application data that is being passed over a session connection. Since application data can be mixed with Telnet protocol command data, both Telnet clients and servers are obligated to scan for Telnet protocol command data in every packet exchanged by client and server endpoints. Telnet protocol commands are identified within a data packet by a flag character called an Interpret As Command (IAC), which is a hexadecimal 0xFF byte. When this IAC flag byte is found in a data packet, the Telnet client and/or server must inspect the byte(s) that follow to see if the 0xFF byte is meant to be an application data byte, or is really an IAC flag byte. This ambiguity exists because hexadecimal code points in the American Standard Code for Information Interchange (ASCII) character set used for Telnet protocol commands are also valid as application data. RFC 854 deals with this ambiguity by declaring a mechanism to "escape" any 0xFF bytes in the application data such that they can be detected apart from IAC flags. To distinguish 0xFF data bytes from a Telnet protocol IAC command, 0xFF data bytes are prefixed with an IAC byte. This prefixing of an 0xFF data byte with an IAC byte is referred to as "doubling", since it results in a string of two 0xFF bytes. Unfortunately, the design of the "escape" mechanism leads to degraded performance and program complexity as a result of the significant effort required to identify and undouble "escaped" data bytes to allow separation of Telnet commands from application data. This performance and complexity can result in slower processing by the applications running on a Telnet client and/or Telnet server, particularly when large data packets of application data are involved. For example, printer passthrough support defined in RFC 2877 (http://www.ietf.org/rfc/rfc2877.txt) will not send any Telnet commands once a Telnet session is established. Since print functions typically involve massive amounts of binary print information that is not of interest to a Telnet server or client (it is "passed through"), it makes no sense to spend many CPU cycles scanning data packets for IAC flag characters that identify Telnet commands. Thus, print functions are a specific example of an application that can benefit from not having to process IAC flags and Telnet commands. Other potential applications could be faxes, graphics, Secure Sockets Layer (SSL) certificates, Kerberos tickets, etc. This performance problem may be greatly magnified in a situation where dedicated workstations are used as a printer farm. With a printer farm, many Telnet printer passthrough sessions are initiated from a single workstation. These Telnet printer passthrough sessions connect a virtual printer device on an iSeries system to a physical printer located anywhere that is reachable by the network on which the workstation is located. For the sake of illustration, suppose at a given point in time that 35 jobs are being printed in a printer farm, where all jobs are using different Telnet printer passthrough sessions. All these jobs will be routed through the workstation managing the printer farm. If each print job averages 150 KB of data, then the managing workstation has to expend enough CPU cycles to process 5.25 MB of data. This processing includes checking each byte of each packet to scan for "escape" data bytes and IAC bytes even though most of the data packets will not contain any 0xFF bytes.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 33% of the total text.

Page 1 of 3

  Mechanism for Selective 5250 Architecture Bypass of Telnet Protocol Command and Escape Byte Processing

    In a TCP/IP network that uses a Telnet client/server protocol, applications running on a Telnet server platform may exchange data over a Telnet session connection to applications running on a Telnet client platform. In addition to applications passing data over this Telnet session connection, the Telnet server and client may also pass Telnet Protocol commands over the same session connection. The exchange of application data and Telnet commands adhere to the rules defined in Request For Comments (RFC) 854, which can be found at the Internet Engineering Task Force (IETF) web site as http://www.ietf.org/rfc/rfc854.txt

It should be noted that Telnet protocol commands are asynchronous, and may occur in the middle of application data that is being passed over a session connection. Since application data can be mixed with Telnet protocol command data, both Telnet clients and servers are obligated to scan for Telnet protocol command data in every packet exchanged by client and server endpoints. Telnet protocol commands are identified within a data packet by a flag character called an Interpret As Command (IAC), which is a hexadecimal 0xFF byte. When this IAC flag byte is found in a data packet, the Telnet client and/or server must inspect the byte(s) that follow to see if the 0xFF byte is meant to be an application data byte, or is really an IAC flag byte. This ambiguity exists because hexadecimal code points in the American Standard Code for Information Interchange (ASCII) character set used for Telnet protocol commands are also valid as application data. RFC 854 deals with this ambiguity by declaring a mechanism to "escape" any 0xFF bytes in the application data such that they can be detected apart from IAC flags. To distinguish 0xFF data bytes from a Telnet protocol IAC command, 0xFF data bytes are prefixed with an IAC byte. This prefixing of an 0xFF data byte with an IAC byte is referred to as "doubling", since it results in a string of two 0xFF bytes. Unfortunately, the design of the "escape" mechanism leads to degraded performance and program complexity as a result of the significant effort required to identify and undouble "escaped" data bytes to allow separation of Telnet commands from application data.

This performance and complexity can result in slower processing by the applications running on a Telnet client and/or Telnet server, particularly when large data packets of application data are involved. For example, printer passthrough support defined in RFC 2877 (http://www.ietf.org/rfc/rfc2877.txt) will not send any Telnet commands once a Telnet session is established. Since print functions typically involve massive amounts of binary print information that is not of interest to a Telnet server or client (it is "passed through"), it makes no sense to spend many CPU cycles scanning data packets for IAC flag characters that ident...