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

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...