|
|
|
|
|
|
Configuring JET for Client Access
This topic includes the following sections:
The section Configuring JET provides the instructions you need to configure JET for client access. You need to complete these instructions only if you need to add or edit BEA Tuxedo service definitions using either of the following client programs: the Bulk Loader program or the Jolt Repository Editor. The section JET Administrative Reference provides supplemental reference information.
Note: Throughout this topic, the term client refers to either the Bulk Loader or the Jolt Repository Editor.
This topic assumes that you are familiar with BEA Tuxedo and that you have experience with the operating systems and network environment in which you are configuring JET. It also assumes that you have already configured the Jolt Repository Server (JREPSVR) according to the configuration instructions in Configuring JET for Java Server Access.
Configuring JET
This topic provides instructions for configuring JET for client access. It includes the following sections:
About Configuring JET for Client Access
Before you can use the Bulk Loader program or Jolt Repository Editor to add or edit BEA Tuxedo service definitions, you must configure and start the following servers:
For an introduction to these components, see Tools for Managing Service Definitions.
Note: Before you proceed with this topic, you first need to configure the Jolt Repository Server (JREPSVR) according to the configuration instructions in Configuring JET for Java Server Access.
For more information about the UBBCONFIG file, see "Creating a Configuration File" in the Administration Guide.
Step 1: Configure JSL
To configure JET for client access, you must configure the JSL on the host on which the BEA Tuxedo services that you want to invoke are running. You configure the JSL in the UBBCONFIG file. For an introduction to the JSL, see Jolt Servers. For additional information about configuration parameters, see Jolt Server Reference.
Note: Before you begin, be sure to set the CLASSPATH to include the directory in which the jolt.jar file resides (such as udataobj\jolt).
To configure the JSL:
Note: If MAXWSCLIENTS is not set, JSL does not boot.
Lines within this section have the form:
JSL required parameters [optional parameters]
where JSL specifies the filename (string_value) of the JSL to be executed by tmboot(1), as described in the following step.
SVRGRP=string_value
SRVID=number
CLOPT="-A...-n...//host port"
For more information about these parameters, see "Creating a Configuration File" in the Administration Guide.
MIN # of JSHs
MAX # of JSHs
Upon startup, the JSL starts the configured minimum number of JSHs. As more concurrent requests are received, it might start additional JSHs to handle the request load, up to the configured maximum number of JSHs.
To use these parameters, you first need to understand how doing so affects your application. For more information about these parameters, see "Creating a Configuration File" in the Administration Guide.
Step 2: Configure Jolt Relay
To configure JET for client access across a firewall, you must also configure Jolt Internet Relay, which includes the following components:
Note: You do not need to configure Jolt Relay if no firewall exists between client programs and the JSL.
For an introduction to Jolt Internet Relay, see Jolt Internet Relay. For additional information about configuration parameters, see Jolt Internet Relay Reference.
Configuring JRLY on the Web Server
To configure JRLY, you first start JRLY on the Web server and then change the configuration file. Be sure to follow the instructions for your Web server platform-the instructions for UNIX and Windows NT are slightly different. For a detailed description of JRLY configuration parameters, see Jolt Internet Relay Reference.
Note: The format for directory and filenames is determined by the operating system. UNIX systems use the forward slash (/). Windows NT systems use the backslash (\). If any files specified in LOGDIR, ACCESS_LOG, or ERROR_LOG cannot be opened for writing, JRLY prints an error message on stderr and exits.
Installing and Starting JRLY (Windows NT Only)
JRLY runs as an NT service in the Windows NT environment. To install JRLY on the Web server machine, complete the following steps:
jrly -install
By default, the JRLY service is configured to start automatically.
jrly -set -f c:\tux71\udataobj\jolt\jrly.config
In this example, the default JRLY Windows NT service (Jolt Relay) is assigned a configuration file called jrly.config that is located in the following directory: c:\tux71\udataobj\jolt.
Starting JRLY (UNIX Only)
Start the JRLY process on UNIX by typing the following command at the system prompt:
jrly -f config_file
where config_file is the path and name of the JRLY configuration file. The default filename is jrly.config.
Note: If the specified configuration file does not exist or it cannot be opened, the JRLY writes a message to stderr, attempts to log the startup failure in the error log, and then exits.
Configuring JRLY (UNIX and Windows NT)
The configuration file uses a TAG=VALUE syntax. Blank lines or lines starting with the # character are ignored. Listing 3-1 shows an example of the formal specifications of the configuration file.
Listing 3-1 Formal Configuration File Specifications
LOGDIR=<LOG_DIRECTORY_PATH>
ACCESS_LOG=<ACCESS_FILE_NAME in LOGDIR>
ERROR_LOG=<ERROR_FILE_NAME in LOGDIR>
LISTEN=<IP:Port combination where JRLY will accept comma-separated connections>
CONNECT=<IP:Port1, IP:Port2...IP:PortN:Port(List of IP:Port combinations associated with JRADs: can be 1...N)>
Configuring the Socket Timeout (Windows NT only; optional)
The SOCKETTIMEOUT setting is specified in the JRLY configuration file. SOCKETTIMEOUT is the time, in seconds, for which JRLY Windows NT service blocks for network activity (new connections, data to be read, and closed connections). SOCKETTIMEOUT also affects the Service Control Manager (SCM). When the SCM requests the Windows NT service to stop, the SCM must wait for at least SOCKETTIMEOUT seconds before quitting.
Table 3-1 describes the formats for the host names and the port numbers.
|
Host Name/Port # |
Description |
|---|---|
|
//Hostname:Port |
Hostname is a string; Port is a decimal number. |
|
IP:Port |
IP is a dotted notation IP address; Port is a decimal number. |
Configuring JRAD in the Tuxedo Environment
To configure JRAD, a Tuxedo server, you first start JRAD in the BEA Tuxedo environment and then change the configuration file.
Starting the Jolt Relay Adapter (JRAD)
To start the Jolt Relay Adapter, complete the following steps:
Configuring the JRAD
While configuring the JRAD, consider the following rules:
To configure the JRAD, complete the following steps:
Note: The format is 0x0002PPPNNN or, in dot notation, 100.100.10.100.
Step 3: Registering Tuxedo Services with the Repository
In order to make the JET services available to Java servers, you must define the BEA Tuxedo services that use BEA Tuxedo. To define the Tuxedo service:
Note: You cannot use the Bulk Loader or Jolt Repository Editor until the JREPSVR and JSL are properly configured and running. In addition, if a firewall exists between the Jolt Repository Editor and the JSL, Jolt Internet Relay must also be properly configured and running.
JET Administrative Reference
This topic includes detailed supplemental reference information for the following JET components:
This section provides supplemental reference information for the Jolt Listener (JSL) and Jolt Handler (JSH). For an introduction to these servers, see Jolt Servers. For configuration instructions, see Step 1: Configure JSL.
About Jolt Servers
JET provides the following Jolt servers:
System Administrator Responsibilities
The system administrator's responsibilities for the Jolt servers include:
After you have configured the JSL in the UBBCONFIG file, you need to complete the following steps on the Tuxedo server to start all administrative and server processes in the UBBCONFIG file:
This command parses the configuration file and loads the binary version of the configuration file.
This command activates the application specified in the configuration file.
If you do not enter any options, a prompt asks you if you really want to overwrite your TUXCONFIG file.
See Administering a BEA Tuxedo Application at Run Time or the BEA Tuxedo Command Reference for information about tmloadcf and tmboot.
Shutting Down the JSL
All shutdown requests to the Jolt servers are initiated by the BEA Tuxedo command:
tmshutdown -y
During shutdown:
BEA Tuxedo monitors the JSL and restarts it in the event of a failure. When BEA Tuxedo restarts the listener process, the following events occur:
The Jolt Server Listener (JSL) is a BEA Tuxedo server that is responsible for distributing connection requests from JET to an available Jolt Server Handler (JSH). BEA Tuxedo must be running on the host machine where the JSL and the JREPSVR are located.
JSL Command-Line Options
The server may need to obtain information from the command-line. The CLOPT parameter allows you to specify command-line options that can change some defaults in the server. Table 3-2 describes the JSL command-line options.
|
Option |
Description |
|---|---|
|
[-c compression_threshold] |
Enables application data sent between a JET client and a Jolt server (JSH) to be compressed during transmission over the network. compression_threshold is a number that you specify between 0 and 2,147,483,647 bytes. Any messages that are larger than the specified compression threshold are compressed before transmission. The default is no compression; that is, if no compression threshold is specified, messages are not compressed on client or server. The previous -c connection-mode option has been replaced with the -j connection-mode option. |
|
[-d device_name] |
The device for platforms using the Transport Layer Interface. There is no default. Required. (Optional for sockets) |
|
[-H external netaddr] |
external netaddr is the network address JET that clients use to connect to the application. The JSL process uses this address to listen for clients attempting to connect at this address. If the address is 0x0002MMMMdddddddd and JSH network address is 0x00021111ffffffff, the known network address is 0x00021111dddd dddd. If the address starts with // network address, the type is IP based and the TCP/IP port number of JSH network address is copied into the address to form the combined network address. The IP address must be specified in the following format: -H //external ip address:MMMM (Optional for JSL in BEA Tuxedo 6.4 and 6.5) |
|
[-I init-timeout] |
The time (in seconds) that a JET client is allowed to complete initialization through the JSH before it is timed out by the JSL. Default is 60 seconds. (Optional) |
|
[-j connection_mode] |
The following connection modes from clients are allowed:
The default is ANY. That is, if no option is specified, the server allows a client to request either a RETAINED or RECONNECT type of connection. (Optional) Note: This option has been changed in this release from -c [connection_mode] to -j [connection_mode].
|
|
[-m minh] |
The minimum number of JSHs that are available in conjunction with the JSL at one time. The range of this parameter is from 0 through 255. Default is 0. (Optional) |
|
[-M maxh] |
The maximum number of JSHs that are available in conjunction with the JSL at one time. If this option is not specified, the parameter defaults to MAXWSCLIENTS divided by the rounded-up -x multiplexing factor (MPX). If specified, the -M option takes a value from 1 to 32767. (Optional) |
|
[-n netaddr] |
Network address used by the Jolt listener with BEA Tuxedo 6.4 and 6.5, and WebLogic Enterprise 4.2, 5.0, and 5.1. TCP/IP addresses may be specified in the following formats: "//host.name:port_number" In the first format, the domain finds an address for hostname by using the local name resolution facilities (usually DNS). hostname must be the local machine, and the local name resolution facilities must unambiguously resolve hostname to the address of the local machine. This command-line option indicates the Jolt Server Handler. Default is JSH. (Optional) In the second example, the #.#.#.# is in dotted decimal format. In dotted decimal format, each # should be a number from 0 to 255. This dotted decimal number represents the IP address of the local machine. In both of the above formats, port_number is the TCP port number at which the domain process listens for incoming requests. port_number can either be a number between 0 and 65535 or a name. If port_number is a name, then it must be found in the network services database on your local machine. The address can also be specified in hexadecimal format when preceded by the characters "0x". Each character after the initial "0x" is a number from 0 to 9 or a letter from A to F (case insensitive). The hexadecimal format is useful for arbitrary binary network addresses such as IPX/SPX or TCP/IP. There is no default. (Required) |
|
[-T Client-timeout] |
The time (in minutes) allowed for a client to stay idle. If a client does not make any requests during this time, the JSH disconnects the client and the session is terminated. If an argument is not supplied, the session does not timeout. When the -j ANY or -j RECONNECT option is used, always specify -T with an idle timeout value. If -T is not specified and the connection is suspended, JSH does not automatically terminate the session. The session never terminates if a client abnormally ends the session. If a parameter is not specified, the default is no timeout. (Optional) |
|
[-w JSH] |
This command-line option indicates the Jolt Server Handler. Default is JSH. (Optional) |
|
[-x mpx-factor] |
The number of clients that one JSH can service. Use this parameter to control the degree of multiplexing within each JSH process. If specified, this parameter takes a value from 1 to 32767 for UNIX and Windows NT. Default value is 10. (Optional) |
|
[-Z 0|40|128] |
When a network link between a JET client and the JSH is being established, this option allows encryption up to the specified level.The initial 0 means no DH nodes, no RC4. The numbers 56 and 128 specify the length (in bits) of the encryption key. The DH key exchange is needed to generate keys. Session keys are not transmitted over the network. The default value is 0. |
Sample UBBCONFIG Settings for JSL
Listing 3-2 shows relevant portions of the UBBCONFIG file configured for JSL.
Listing 3-2 Sections of UBBCONFIG File Related to JSL Configuration
*MACHINES
MACH1 LMID=SITE1
MAXWSCLIENTS=40
*GROUPS
JSLGRP GRPNO=95 LMID=SITE1
*SERVERS
JSL SRVGRP=JSLGRP SRVID=30 CLOPT= " -- -n 0x0002PPPPNNNNNNNN -d
/dev/tcp -m2 -M4 -x10"
The parameters shown in Table 3-3 are the only parameters that must be designated for the Jolt server groups and Jolt servers. You are not required to specify any other parameters.
|
Section |
Parameters to Specify |
|---|---|
|
MACHINES |
MAXWSCLIENTS |
|
GROUPS |
GRPNO, LMID |
|
SERVERS |
SRVGRP, SRVID, CLOPT |
For more information about these parameters, see "Creating a Configuration File" in the Administration Guide.
MACHINES Section
The MACHINES section must contain an entry for each physical processor used by the application. Entries have the form:
ADDRESS or NAME required parameters [optional parameters]
where ADDRESS is the physical name of the processor, for example, the value produced by the UNIX system uname -n command.
LMID=string_value
This parameter specifies that the string_value is to be used in other sections as the symbolic name for ADDRESS. This name cannot contain a comma, and must be 30 characters or less. This parameter is required. There must be an LMID line for every machine used in a configuration.
MAXWSCLIENTS=number
The MAXWSCLIENTS parameter is required in the MACHINES section of the configuration file. It specifies the number of accessor entries on this processor to be reserved for Jolt and Workstation clients only. The value of this parameter must be between 0 and 32768, inclusive.
The Jolt server and Workstation use MAXWSCLIENTS in the same way. For example, if 200 slots are configured for MAXWSCLIENTS, this number configures BEA Tuxedo for the total number of remote clients used by Jolt and Workstation.
Note: Be sure to specify MAXWSCLIENTS in the configuration file. If it is not specified, the default is 0.
Note: If MAXWSCLIENTS is not set, the JSL does not boot.
GROUPS Section
A GROUPS entry is required for the group that includes the Jolt Server Listener (JSL). Make the GROUPS entry as follows:
Note: Make sure that Resource Managers are not assigned as a default value for all groups in the GROUPS section of your UBBCONFIG file. Making Resource Managers the default value assigns a Resource Manager to the JSL and you receive an error during tmboot. In the SERVERS section, default values for RESTART, MAXGEN, and so on, are acceptable defaults for the JSL.
Lines within the GROUPS section have the form:
GROUPNAME required parameters [optional parameters]
where GROUPNAME specifies the logical name (string_value) of the group. The group name must be unique within all group names in the GROUPS section and LMID values in the MACHINES section. The group name cannot contain an asterisk(*), comma, or colon, and must be 30 characters or less.
SERVERS Section
Clients connect to Jolt Repository through the Jolt Server Listener (JSL). Services are accessed through the Jolt Server Handler (JSH). The JSL supports multiple clients and acts as a single point of contact for all the clients to connect to the application at the network address that is specified on the JSL command-line. The JSL schedules work for handler processes. A handler process acts as a substitute for clients on remote workstations within the administrative domain of the application. The handler uses a multiplexing scheme to support multiple clients on one port concurrently.
The network address specified for the JSL designates a TCP/IP address for both the JSL and any JSH processes associated with that JSL. The port number identified by the network address specifies the port number on which the JSL accepts new client connections. Each JSH associated with the JSL uses consecutive port numbers at the same TCP/IP address. For example, if the initial JSL port number is 8000 and there are a maximum of three JSH processes, the JSH processes use ports 8001, 8002, and 8003.
Note: Be sure to provide sufficient space between JSL port numbers (for example, use 8000, 8020, 8040, etc. for JSL port numbers). Misconfiguration of subsequent JSL port numbers results in a port number collision.
Security and Encryption
Authentication and key exchange data are transmitted between JET clients and the JSL/JSH using the DES key exchange and a 128-bit key, with 40 bits encrypted and 88 bits exposed.
Jolt Internet Relay Reference
This section provides supplemental reference information for the Jolt Relay (JRLY) and its associated Jolt Relay Adapter (JRAD). For an introduction to these components, see Jolt Internet Relay. For configuration instructions, see Step 2: Configure Jolt Relay.
About Jolt Relay and the Jolt Relay Adapter
The combination of the Jolt Relay (JRLY) and its associated Jolt Relay Adapter (JRAD) is typically referred to as the Internet Relay. Jolt Relay routes messages from a JET client to a JSL or JSH. This eliminates the need for the JSH and BEA Tuxedo to run on the same machine as the Web server (which is generally considered insecure). The Jolt Relay consists of the following two components:
Note: The Jolt Relay is transparent to Java clients and servers. A Jolt server can simultaneously connect to Intranet clients directly, or through the Jolt Relay to Internet clients.
This section describes configuration options for JRLY.
Jolt Relay Failover
There are two points of failovers associated with JRLY:
Jolt Client to JRLY Connection Failover
If one server address does not result in a successful session, the failover function allows the Jolt Client API to connect to the next free (unconnected) JRLY specified in the argument list of the API. To enable this failover in the Windows NT environment, multiple Windows NT JRLY services can be executed. In a non-NT environment, multiple JRLY processes are executed. Each JRLY (service or process) has its own configuration file. This type of failover is handled by client API features that allow you to specify a list of Jolt server addresses (JSL or JRLY).
JRLY to JRAD Adapter Connection Failover
Each JRLY configuration file has a list of JRAD addresses. When a JRAD is unavailable, JRLY tries to connect to the next free (unconnected) JRAD, in a round-robin fashion. Two JRLYs cannot connect to the same JRAD. However, you can make the connection efficient by giving different JRAD address orders-if you make one extra JRAD available on standby, the first JRLY that loses its JRAD connects to the extra JRAD. This type of failover is handled by JRLY alone.
If any of the listed JRADs are not executing when JRLY is started, the initial connection fails. When a JET client tries to connect to JRLY, the JRLY again tries to connect to the JRAD.
To accommodate the failover functionality, you need to boot multiple JRADs by configuring them in the UBBCONFIG file.
Jolt Relay Process
The JRLY (frontend relay) process can be started before or after the JRAD is started. If the JRAD is not available when the JRLY is started, the JRLY attempts to connect to the JRAD when it receives a client request. If JRLY is still unable to connect to the JRAD, the client is denied access and a warning is written to the JRLY error log file.
Starting the JRLY on UNIX
Start the JRLY process by typing the command name at a system prompt:
jrly -f config_file
where config_file is the path and name of the JRLY configuration file. The default filename is jrly.config. If the configuration file does not exist or cannot be opened, the JRLY prints an error message. For information about JRLY error messages, see the System Messages in the WebLogic Enterprise online documentation.
If the JRLY is unable to start, it writes a message to stderr and attempts to log the startup failure in the error log (specified in the JRLY configuration file), and then exits.
JRLY Command-Line Options for Windows NT
This section describes command-line options that are available for the Windows NT version of JRLY.exe. Note the following:
Table 3-4 describes the JRLY command-line options.
|
Option |
Description |
|---|---|
|
jrly -install [display_suffix] |
Installs jrly as a Windows NT service. Example 1: jrly -install In this example, the default JRLY is installed as a Windows NT service and is displayed in the Service Control Manager (SCM) as Jolt Relay. Example 2: jrly -install MASTER In this case, an instance of JRLY is installed as a Windows NT service and is displayed in the SCM as Jolt Relay_MASTER. The suffix, MASTER, does not have any significance; it is only used to uniquely identify various instances of JRLYs. At this point, this instance of JRLY is not ready to start. It must be assigned the configuration file (see the set command discussion) that specifies the listening TCP/IP port, JSH connection TCP/IP port, log files, and SOCKETTIMEOUT). This file should not be shared between various instances of JRLY. |
|
jrly -remove [display_suffix] | -all |
Removes one or all instances of JRLY from a Windows NT service. If [display_suffix] is specified, this command removes the specified JRLY service. If [display_suffix] is not specified, this command removes the default JRLY from being a Windows NT service. If the -all option is specified, all JRLY Windows NT services are removed. Related Windows NT registry entries are removed. |
|
jrly -set |
Updates the registry with the full path of a new configuration file. Example 1: jrly -set -f c:\tux71\udataobj\jolt\jrly.config In this example, the default JRLY Windows NT service (Jolt Relay) is assigned a configuration file called jrly.config that is located in c:\tux71\udataobj\jolt directory. Example 2: jrly -set -d MASTER -f c:\tux71\udataobj\jolt\master.con Here, the JRLY Windows NT service instance, called Jolt Relay_MASTER is assigned a configuration file called jrly_master.con that is located in c:\tux71\udataobj\jolt directory. |
|
jrly -manual [display_suffix] |
Sets the start/stop to manual. This command sets the specified JRLY instance to be manually controlled, using either the command-line options or the SCM. |
|
jrly -auto [display_suffix] |
Sets the start/stop to automatic. This command sets all the operations for the specified Windows NT service to be automatically started when the OS boots and stopped when the OS shuts down. |
|
jrly -start [display_suffix] |
Starts the specified JRLY. |
|
jrly -stop [display_suffix] |
Stops the specified JRLY. |
|
jrly -version |
Prints the current version of JRLY binary. |
|
jrly -help |
Prints command-line options with brief descriptions. |
JRLY Command-Line Option for UNIX
Table 3-5 describes the one JRLY command-line option for UNIX.
|
Option |
Description |
|---|---|
|
jrly -f config_file |
Starts the JRLY process. This option starts the JRLY process with the specified configuration file (path and name). If the configuration file does not exist or cannot be opened, the JRLY prints an error message. If the JRLY cannot start, it writes a message to stderr, attempts to log the startup failure in the error log, then exits. |
The format of the configuration file is a TAG=VALUE format. Blank lines or lines starting with the # character are ignored. Listing 3-3 contains an example of the formal specifications of the configuration file.
Listing 3-3 Specification of Configuration File
LOGDIR=<LOG_DIRECTORY_PATH>
ACCESS_LOG=<ACCESS_FILE_NAME in LOGDIR>
ERROR_LOG=<ERROR_FILE_NAME in LOGDIR>
LISTEN=<IP:Port combination where JRLY will accept connections>
CONNECT=<IP:Port combination associated with JRAD>
SOCKETTIMEOUT=<Seconds for socket accept()function>
SOCKETTIMEOUT is the duration (in seconds) of which the relay Windows NT service blocks the establishment of new socket connections to allow network activity (new connections, data to be read, closed connections). It is valid only on Windows NT machines. SOCKETTIMEOUT also affects the SCM. When the SCM requests that the service stop, the SCM needs to wait at least SOCKETTIMEOUT seconds before doing so.
Listing 3-4 shows an example of the JRLY configuration file. The CONNECT line specifies the IP address and port number of JRAD machine.
Listing 3-4 Example of JRLY Configuration File
LOGDIR=/usr/log/relay
ACCESS_LOG=access_log
ERROR_LOG=errorlog
# jrly will listen on port 4444
LISTEN=200.100.10.100:4444
CONNECT=200.100.20.200:4444, 200.100.20.200:5555,...
SOCKETTIMEOUT=30 //See text under listing
The format for directory and filenames is determined by the operating system. UNIX systems use the forward slash (/). Windows NT systems use the backslash (\). If any file specified in LOGDIR, ACCESS_LOG or ERROR_LOG cannot be opened for writing, the JRLY prints an error message on stderr and exits.
Table 3-6 describes the formats for host names and port numbers.
|
Host Name/Port # |
Description |
|---|---|
|
Hostname:Port |
Hostname is a string, Port is a decimal number. |
|
//Hostname:Port |
Hostname is a string, Port is a decimal number. |
|
IP:Port |
IP is a dotted notation IP address, Port is a decimal number. |
The Jolt Relay Adapter (backend relay) is a BEA Tuxedo system server. The Jolt Relay Adapter (JRAD) server may or may not be located on the same BEA Tuxedo host machine in single host mode (SHM) and server group to which the JSL server is connected.
The JRAD can be started independently of its associated JRLY. JRAD tracks its startup and shutdown activity in the BEA Tuxedo log file.
JRAD Configuration
A single JRAD process can only be connected to a single JRLY. A JRAD can be configured to communicate with only one JSL and its associated JSHs. However, multiple JRADs can be configured to communicate with one JSL. The CLOPT parameter for the BEA Tuxedo servers must be included in the UBBCONFIG file. Listing 3-5 shows a sample of the file.
Table 3-7 describes additional information about the CLOPT parameters.
|
CLOPT Parameter |
Description |
|---|---|
|
-l hexadecimal format |
Port to listen for the JRLY to connect on behalf of the client. |
|
-c hexadecimal format |
The address of the corresponding JSL to which JRAD connects. |
|
-H hexadecimal format |
Used when there is a network address translation performed for JRLY listen address. |
Note: The format is 0x0002PPPPNNN.
Listing 3-5 Sample JRAD Entry in UBBCONFIG File
# JRAD host 200.100.100.10 listens at port 2000, connects to JSL port 8000 on the same host
JRAD SRVGRP=JSLGRP SRVID=60
CLOPT="-A -- -l 0x000207D0C864640A -c 0x00021f40C864640A"
Network Address Configurations
A Jolt Internet Relay configuration requires that several networked components work together. Prior to configuration, review the criteria in Table 3-8 and record the information to minimize the possibility of misconfiguration.
|
JRLY |
JRAD |
JSL |
|---|---|---|
|
LISTEN: Location where the clients connect CONNECT: Location of your JRAD. Must match the -l parameter of JRAD |
-l: Location where the listener connects to the JRLY -c: Location of JSL. Must match -n parameter of JSL |
-n: Location of JSL. Must match -c parameter of JRAD |
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|