System and Method for Negotiating Functions and Features

1. Technical Field of the Invention

This invention pertains to client and server negotiation of functions and features. In particular, this invention provides a functional interface at the client which initially connects to and conducts features and function negotiations with the server on behalf of the client, and thereafter exchanges data streams between the server and the client.

2. Background Art

Today, most Telnet clients lack the ability to implement RFC 1572 extensions, whereby negotiations with an AS/400 Telnet server occur to establish a specific device type, code page, character set, and so forth, for a desired Telnet connection. The RFC 1572 protocol is described in Network Working Group, Telnet Environment Option, Request for Comments 1572, January 1994, the teachings of which are incorporated herein by reference.

In order to take advantage of functions and features negotiations provided by RFC 1572, Telenet clients must be modified. These new functions and features include (1) starting specific jobs based upon the device name; (2) restricting application access based on device name; and (3) selecting terminal and keyboard language information by device selection, because virtual devices have national language support attributes already associated with them.

However, modifications to Telnet clients are neither easy nor trivial. Adding RFC support typically requires some kind of client interface update to perform the negotiation.

It is an object of the invention to provide an improved client interface supporting functions and features negotiations.

It is a further object of the invention to provide a client interface that performs negotiations for device name, code page, character set, and the like on behalf of a Telnet client.

It is a further object of the invention to provide a system and method for enabling RFC 1572 negotiations without having to modify the client to support the new options.

It is a further object of the invention to allow enhanced features provided in a Telnet server to be exploited by traditional (or, legacy) Telnet clients.

In accordance with the invention, a system and method is provided for client negotiation of functions and features with a server. An interface controller is provided which, upon being called by a client application, prompts the application for values to be used in the negotiations and, upon obtaining those values, connects to the server to negotiates the desired functions and features. Upon completing the functions and features negotiations, the interface controller starts the client application, which connects to the controller and the controller establishes a session with the server. Thereafter, the controller exchanges data streams between the server and the client.

Other features and advantages of this invention will become apparent from the following detailed description of the presently preferred embodiment of the invention, taken in conjunction with the accompanying drawings.

FIG. 1 illustrates a typical server/client connection in accordance with the prior art.

FIG. 2 illustrates an interface controller for interconnecting a server and client in accordance with the invention.

FIG. 3 illustrates a high level view of the process steps executed by the interface controller of FIG. 2.

FIG. 4 illustrates the process for negotiating certain functions and features in accordance with RFC 1572.

FIG. 5 illustrates the multi-threading structure for the interface controller (or, adapter) of FIG. 2.

FIG. 6 illustrates a sample screen shot for using the client's default options.

FIG. 7 illustrates a sample screen shot for doing environment option negotiations.

FIGS. 8A-8C, related as illustrated in FIG. 8, illustrate a more detailed view of the process steps executed by the interface controller of FIG. 5.

Referring to FIG. 1, in accordance with the prior art, server 100 is connected over a TCP/IP link to client 102, which may be a workstation including a connection 103 to display 104. In accordance with protocols defined in RFC 1572, server 100 and client 102 may negotiate to establish a specific device type, code page, character set, and so forth, for a desired Telnet connection.

Referring to FIG. 2, in accordance with the invention, client application 112 is connected as represented by interface line 117 to interface controller 116. In this preferred embodiment, interface controller is a Java program with a graphical user interface (GUI) represented by line 115 to display 114, and which connects with server 110 over TCP/IP link 111. Client application 112 is also connected by interface 113 to display 114. Controller 116 sits between client 112 and server 110 and handles protocol negotiations before dropping into the steady state function of passing data between client 112 and server 110. While this preferred embodiment of the invention relates to RFC 1572, similar controllers may be provided for other client/server protocols, such as FTP, HTTP, LPR/LPD, and so forth, in addition to other Telnet RFCs besides 1572.

Referring to FIG. 3, in operation, interface controller 116 performs the negotiations for device name, code page, character set, and so forth on behalf of Telnet client 112, thus enabling the function and features that are possible using RFC 1572 protocols, or the like. In step 140, client application 112 calls interface controller 116 which then in step 142 prompts user via graphical user interface (GUI) presentation at display, 114 as is represented by line 115, for the values to use in the negotiations. These values include, for RFC 1572 negotiations, terminal type, user identifier, password, device name, keyboard type, code page, and character set.

Interface 115 is optional, and provides a flexible version of an interface to controller, or adapter, 116 allowing a user to set negotiation values rather than using fixed values from a file or the like. In this sense, step 142 represents obtaining negotiation values from a GUI interface, a file, from system settings, or so forth. A GUI interface is not explicitly required.

Having obtained the negotiation values from the user at workstation display 114, in step 144 interface controller 116 connects to the server 110 over link 111 to negotiate functions and features on behalf of client 112. In step 146, as is represented by line 117, controller 116 kicks off client application 112 which connects to controller 116 (rather than directly to server 110). "Kick off" means to start a separate job or program. Client 112 runs independently of program 116, and in all embodiments of the invention it is not required that program 116 start client 112. While having client 112 started by controller 116 may be a feature, what is required is that controller 116 start before client 112 can connect to it. At what point controller program 116 connects to server 110 is a design issue, but preferably client 112 provides all values it wants to negotiate with server 110 to controller 116, and controller 116 may add some extra negotiations to that existing negotiation stream. Thus, in accordance with this specific embodiment, client 112 may already be building a negotiation (or, control) stream, and controller program 116 adds additional data into that stream and interprets the reply data from server 110 in response to that additional data.

In a preferred embodiment, client 112 establishes a TCP/IP connection 117 to controller 116 once controller 116 has completed Telnet negotiations with server 110, and client 112 simulates the Telnet negotiations with controller 116 (that is, duplicates the negotiations which have been previously carried out).

In accordance with a further embodiment, negotiation streams from both client 112 and controller program 116 are merged. Thus, program 116 passes thru unchanged all client 112 negotiations, and then adds some of its own negotiations after that. In one preferred approach, program 116 receives a negotiation from client 112, and sends it to server 110 with no modifications. Server 112 replies to program 116, which sends the data unchanged to client 112. This continues until program 116 finds a spot in the thread to insert the extra negotiations. Normally, controller program 116 is waiting for a TERMINAL-TYPE negotiation request per RFC 1091 after which it will insert NEW-ENVIRON negotiations). When all negotiations are complete to the satisfaction of server 110, then server 110 sends a sign-on panel to program 116 which passes it unchanged to client 112. At this point, no more negotiations are needed or planned, and adapter program 116 passes data back and forth between server 110 and client 112 and does no other function.

In step 148 controller 116 establishes a session with server 110 over link 111, which is in this preferred embodiment a TCP/IP link, and exchanges data streams between client 112 and server 110. In this embodiment, data streams between server 110 and client 112 over links 111 and 117 are normal telnet data streams.

Referring to FIG. 4, a description of a specific preferred embodiment of the operation of interface controller 116 for executing step 144 is set forth. In this regard, controller 116 makes use of enhancements provided to server 110 to implement RFC 1572 Telnet Environment Option to allow clients to specify the virtual device name of the Telnet session. This is done through the new option negotiation handshaking sequence illustrated in FIG. 4 using the variables set forth in Table 1 Telnet Environment Negotiation Variables. The key here is for Telnet server 110 to inform the Telnet client 112, represented in accordance with this embodiment of the invention by interface controller 116, that a NEW-ENVIRON option can be negotiated. Inasmuch as client 112 is unaware of this option, interface controller obtains the values required for the negotiation from the user at workstation display 114 through a GUI, represented by line 115, and then starts client 112 and drops into a data stream pass through mode between client 112 and server 110.

Referring to FIG. 4, server 110 and interface controller 116 are in communication over Telnet link 111, in a time sequence represented by "t". In step 122, Telnet server 110 sends the Telnet command DO TERMINAL-TYPE. In step 124, interface controller responds on behalf of client 122 with WILL TERMINAL-TYPE. In step 126, Telnet server sends the sub-negotiation command for the terminal type option. In step 128, controller 116 responds to the sub-negotiation terminal type command by sending any valid supported terminal type, in this case the IBM-3487-NC. In step 122, server 110 also tests if the Telnet client (in accordance with this invention, represented by controller 116) is capable of handling negotiations using RFC 1572 by sending a DO NEW-ENVIRON command bundled with the DO TERMINAL-TYPE command; alternatively, this DO NEW-ENVIRON command could be sent following step 128. In step 132, controller 116 responds to the deferred NEW-ENVIRON with the Telnet command WILL NEW-ENVIRON (or, if it cannot support RFC 1572, sends WONT NEW ENVIRON), and defers until step 138 responding to the DO EOR request issued by server 110 at step 130. In step 134, server 110 sends the sub-negotiation command for the environment option. In step 136, controller 116 responds by passing up the environment option information secured, at least in part, from the user at display 114 in step 142. Thus, an appropriate value is selected for a particular client environment. That is, for someone on a Japanese personal computer a USERVAR KBDTYPE of VALUE JKB is sent to get Japanese language support set up with the virtual device created at server 110. Or, since devices can be pre-created with Japanese attributes, alternatively a device is selected which is known to support Japanese, such as USERVAR DEVNAME with VALUE JAPAN001. These are two independent ways to select what is appropriate for the client environment, herein to provide Japanese support at server 110 for a Japanese user at Telnet client 112. Thus, server 110 uses the environment information passed from controller 116 in step 136 to select or create a virtual device description for this session. Assuming negotiation of the environment option completes successfully, server 110 and controller 116 proceed in steps 130 and 138 and thereafter with negotiation of the other Telnet options (e.g., End of Record, Binary) required to initiate a Telnet session. Standard Telnet negotiations, such as End-of-Record, Binary, and so forth are passed between server 110 and client 112. In effect, during such standard negotiations, adapter program 116 is not doing the negotiation but rather letting client 112 respond to server 110. Adapter program 116 inserts and interprets enhanced protocol options (those options or capabilities added to the protocol subsequent to the building of the legacy client 112), such as NEW-ENVIRON or any other custom negotiation.

In accordance with the invention, blocks 132, 134 and 136 make it possible for existing clients to support the new RFC 1572 options without having to modify the client.

Referring to FIG. 5, a specific preferred embodiment of the invention is set forth. Telnet adapter 116 runs between Telnet server 110 and client 150 to enable customers to fully utilize the potential of AS/400 Telnet servers. Telnet 5250 adapter 116 is based, in this specific preferred embodiment, on a Java simulator which, in order to manage all data streams between server and clients, includes a multi-threading structure. Herein, in accordance with that multi-threading structure, server 110 is located at rsOlO.endicott.ibm.com and is listening on port 158 set to port 23. Adapter 116 is located at plewis.endicott.ibm.com, and is listening on port 156 set to port 2134 and on port 154 set to port 23. Client 150 is located at plewis.endicott.ibm.com and is listening on port 152 set to port 1567.

To run adapter program 116, a user enters "java TN5250Adaptor" on a command line, then uses any Telnet client 150 to to connect to the TN5250Adaptor. For example, if the TN5250Adaptor 116 is running on plewis.endicott.ibm.com, and listening for clients on port 23, then a user on Andrew File System (AFS) or AIX can enter "x5250 -sk plewis.endicott.ibm.com" to log on.

Referring to FIG. 6, a sample screen shot of Telnet 5250 Adapter Options 160 is illustrated as presented to the user at display 114. Server name 162 is set to rs010.endicott.ibm.com, server port 158 is set to value "23" and adapter listening port 154 is set to value "23". With button 168 activated, use client's default options is selected, and TN5250Adaptor 116 wont't do anything special, but rather pass raw data between server 110 and client 150.

Referring to FIG. 7, with button 170 activated on option panel 160, TN5250Adaptor 116 will first negotiate with client 150 and negotiate all the Telnet options from the client. When client 150 reaches a state which is ready for data packets, TN5250Adaptor 116 negotiates with server 110 and use all the options specified in option panel 160, including server name 162 of "rs101.endicott.ibm.com", server port 158 of "23", terminal type 178 of value "IBM-3179-2" (or another terminal type entered into field 178 or selected from drop down list 180 by the user), password 186, device name 188 of value "KEVINPTR", keyboard type 190 of "USB", code page 192 of "037", and character set 194 of "697" and any other client options that were negotiated. Buttons 172, 174 and 176 may be activated by the user to connect to server, cancel, or select default options, respectively. Selection of button 182 allows encrypted auto-signon which bypasses the signon screen.

By way of example of a specific implementation of the invention, consider a large chain of hospitals with thousands of patient's nurses using handheld wireless devices to read and update patient information stored on a central computer, such as an IBM AS/400 computer, using one of any number of 25,000 applications developed for the AS/400 and Telnet to access the application on the AS/400 across a wide area network (WAN), as distinguished from a local area network (LAN). Since each nurse running an application represents a job running on the AS/400, thousands of jobs constitute significant workload and resource contention on the AS/400, as further described in copending application S/N 09/050,678, now U.S. Pat. No. 5,946,465, the teachings of which are incorporated herein by reference. In accordance with the present invention, control program 116 provides for selection of the device name used by the nurse (nurse name or ID number). Assuming the nurse is Miss Jones, then in step 136 adapter program 116 inserts into the data stream (or, server communication thread) to server 110, the following:

VAR USER VALUE JONES

USERVAR DEVNAME VALUE JONES001

This allows a nurse to use a specific virtual display device name on server 110, thus enabling server 110 to make that virtual display device "in use" and not capable of reuse until after termination of a user job, thus preventing the nurse who loses her connection from being locked out from using her virtual display device for what could be an unreasonable amount of time.

Referring to FIGS. 8A and 8B in connection with Table 2, the portion of Java source code that performs the negotiation with server and client in accordance with a preferred embodiment of the invention is provided. Line numbers in blocks 200 through 248 refer to the line numbers in Java source code Table 2.

It is an advantage of the method of the preferred embodiment of this invention that new Telnet server functions may be released independently of requiring new Telnet client function. In fact, other types of servers can do similar support for similar clients, this is not necessarily limited to Telnet. This can be a significant cost savings for customers with many clients, and many kinds of clients, which all connect to a single server. They need only get new server code (perhaps for free or as an upgrade) and do not have to pay for client licenses or upgrade costs.

It is a further advantage of the invention that flexibility is provided to extend negotiations as desired, and such need not be limited to language or device possibilities. As long as server support is shipped and the adapter program is used to communicate with the new support, the client side needs have nothing done and customers acquire function for no cost. (In this specific embodiment, adapter 116 may reside at server 110.)

A first complementary embodiment of this invention comprises a programmed general purpose computer. Such a computer is a well known article of commerce, such as the model AS/400 of the International Business Machines Corporation (IBM) or the System/390 of IBM, and is not described further.

It will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without departing from the spirit and scope of the invention. In particular, it is within the scope of the invention to provide a memory device, such as a transmission medium, magnetic or optical tape or disc, or the like, for storing signals for controlling the operation of a computer according to the method of the invention and/or to structure its components in accordance with the system of the invention.

Accordingly, the scope of protection of this invention is limited only by the following claims and their equivalents.