Connection Properties and Telnet Connection Information

Overview of Connection Properties and Telnet Connection Information

The property values used by a SAS/CONNECT driver for Java program connecting to a Telnet daemon (or the spawner) map directly to the Telnet connection information that is passed when manually establishing a remote SAS session using Telnet. This section describes the relationship between the prompt/response pairs that you define as connection properties and the Telnet connection information that is passed when manually establishing a connection.

Note: In the case of SAS/CONNECT driver for Java applets, the connection property values are specified through the use of connection parameters in the applet HTML file.

Telnet Example

To better explain how the SAS/CONNECT driver for Java properties are used to start a remote SAS session using Telnet, let's look at what happens when this operation is done manually.

The user wants to run SAS/CONNECT software on a remote host named myhost. Myhost has a Telnet daemon running and listening on a port. If the user telnets to myhost, the sequence of requests from myhost and responses from the user might look like the following:

Login: myuserid
Password: mypassword

There may be additional textual information sent from the remote Telnet session 
indicating the user has logged on.

Hostname> sas -dmr -noterminal -nosyntaxcheck

SAS(R) TCPIP REMOTE LINK PORT=1763         SESSION ESTABLISHED.

The Telnet daemon provides the prompt for the user to log in. In this example, the login prompt is Login:. The user responds with myuserid. The password prompt is Password: and the user response is mypassword. The command prompt is Hostname>, and the user response is the command to start the SAS/CONNECT session: sas -dmr -noterminal -nosyntaxcheck.

The SAS session responds with a message that states which port it uses for communication with the client, PORT=, followed by the port number (in this case, port number 1763).

Mapping Connection Properties to Telnet Connection Information

Just as the user receives certain prompts from the Telnet session and responds to them, the connection client (specifically, TelnetConnectClient or TunneledConnectClient) behaves the same way. It waits for certain prompts from the Telnet or spawner session (or from the tunnel feature's server programs) and then responds.

The prompt/response pairs that you need depend on which connection daemon you are using. You can create all the prompt and response properties required to pass the information that your connection daemon requires, using the following format:

promptx

Where x is any number, and the value corresponds to the prompt that you want to pass.

responsex

Where x is any number, and the value corresponds to the connection information that you want to pass.

It is important that you label prompt/response pairs in numerical order, without skipping any numbers. For example, if you create a prompt5/response5 pair, but you do not define a prompt4/response4 pair, the prompt5/response5 properties are ignored and the connection fails.

Note: All but one of the connection properties is created using this format. One property, sasPortTag, is hardcoded to specify the port tag.

Extending the example provided here, the following illustrates how to specify the required connection information using three prompt/response pairs. In this case, we are using connection properties to meet the most common requirements:

The user name prompt is specified using the prompt1 property; the user name response is specified using the response1 property.
The password prompt is specified using the prompt2 property; the password response is specified using the response2 property.
The command prompt is specified using the prompt3 property; the command response is specified using the response3 property.

The prompt/response pairs needed for this example are as follows:

(prompt1, Login:)

The connection client uses this value to determine when it should send the user name response.

Note: The prompt1 value is a substring that the connection client compares with the message from the Telnet session. It must be a unique substring. If the complete Telnet message is Login:, the value in: would be a valid prompt1 value because it uniquely identifies the login prompt. A colon (:) would not be a valid prompt1 value because it is not a unique identifier. The connection client would not know what information to prompt the user for, and the connection to the remote system would fail.

(response1, myuserid)

The connection client sends this response after it has received the user name prompt from the Telnet session.

(prompt2, Password:)

The connection client uses this value to determine when it should send the password response.

Note: The prompt2 value is a substring that the connection client compares with the message from the Telnet session. It must be a unique substring. If the complete Telnet message is Password:, the value word: would be a valid prompt2 value because it uniquely identifies the password prompt. A colon (:) would not be a valid prompt2 value because it is not a unique identifier. The connection client would not know what information to prompt the user for, and the connection to the remote system would fail.

(response2, mypassword)

The connection client sends this response after it has received the password prompt from the Telnet session.

(prompt3, Hostname>)

The connection client uses this value to determine when it should send the command.

Note: The prompt3 value is a substring that the connection client compares with the message from the Telnet session. It must be a unique substring. If the complete Telnet message is Hostname>, greater than (>) would be a valid prompt3 value because it uniquely identifies the command prompt.

(response3, sas -dmr -noterminal -nosyntaxcheck)

This is the complete response to the command prompt.

(sasPortTag, PORT=)

This uniquely identifies that the SAS session has completed initialization and allows the connection client to parse the port value from the message.

Note: The sasPortTag value must be the substring that immediately precedes the port value. Although the substring ESTABLISHED uniquely identifies the message, it does not immediately precede the port number, and the connection client fails to establish a connection to the SAS session.