Network Considerations

It can be useful to regulate the amount of bandwidth used by server processes such as the RTserver and RTgms in your system. To regulate RTserver and RTgms bandwidth usage, a token bucket algorithm is used as a model. Tokens are accumulated steadily as time passes. The amount of data the RTserver or RTgms process is permitted to pass into the network for a particular connection is indicated by the number of tokens that have accumulated for that connection. Each token is a byte of data.

Bandwidth Rate Control Options

Several options have been added to implement this model. For each type of connection that an RTserver has (to an RTclient, to another RTserver, to an RTgms process), there is:

an option that specifies the rate at which tokens accumulate for the connection

an option that specifies the maximum number of tokens allowed to accumulate for the connection

an option that specifies the amount of time RTserver waits, after it runs out of tokens, for more tokens to accumulate before resuming the sending of data

When you set these options for an RTserver, they apply to the data and messages RTserver sends across the specific type of connection. They do not apply to data or messages received by the RTserver.

These options also exist for RTgms, for the group channel between an RTgms process and an RTserver. When you set these options for RTgms, they apply only to the data and multicast messages RTgms sends up the group channel to an RTserver.

Client_Burst_Interval

Server_Burst_Interval

Server_Max_Tokens

Server_Token_Rate

Setting Bandwidth Rate Control Options

For connections from the RTserver, these options are set in the RTserver startup command file(rtserver.cm) and apply to all connections of each type (RTclient, RTserver, RTgms). To set the options for an individual connection, you can set them dynamically with the T_MT_ADMIN_SET_OUTBOUND_RATE_PARAMS message.

For the group channel from an RTgms process to an RTserver, these options are set in the RTgms startup command file (rtgms.cm) and apply to all group connections. To set the options for an individual group connection, you can set them dynamically with the T_MT_GRP_ADMIN_SET_OUTBOUND_RATE_PARAMS message.

When you send an ADMIN_SET message to a particular RTserver or RTgms process, the options apply to outbound data sent on the specified connection.

For example, if there is a group channel between an RTserver and an RTgms process, using T_MT_ADMIN_SET_OUTBOUND_RATE_PARAMS and specifying a group name sets the options for RTserver for that group channel, controlling the data the RTserver sends to RTgms.

If you use T_MT_GRP_ADMIN_SET_OUTBOUND_RATE_PARAMS and specify the same group name, the options are set for RTgms, and control the data the RTgms sends to RTserver on that same group channel. To control the bandwidth in both directions for a group channel, you must set bandwidth rate control options for both the RTserver and the RTgms.

Handling Network Failures In Publish Subscribe

RTserver and RTclient can take full advantage of the features of connections that detect and recover from network failures. For an introduction to these features, see Handling Network Failures In Publish Subscribe.

Many of the RTserver and RTclient features already discussed in this chapter help to add fault tolerance to SmartSockets:

RTclient can automatically start RTserver if one is not already running (see Finding and Starting RTserver). Note: to allow RTclient to automatically start RTserver, you must use one of the non-default start prefixes described in Start Prefix.

RTclient can restart RTserver and reconnect if an error occurs (see Automatically Reconnecting to RTserver). There are also APF authorization considerations for automatic start and restart on MVS.

RTclient can run with a warm connection to RTserver if the RTserver is temporarily unavailable, such as when a remote node crashes and needs several minutes to reboot (see Warm Connection to RTserver).

RTclient can monitor projects, subjects, RTclients, and RTservers for problems. If a problem is detected, the RTclient makes the appropriate decision to correct the problem (see Chapter 5, Project Monitoring).

RTclient and RTserver can use a list of logical connection names to search for other processes (see Logical Connection Names for RT Processes).

RTclient and RTserver have many options, providing a large degree of control over how many times certain operations are attempted, such as Server_Start_Max_Tries, and how long of a period of time those operations have to complete, such as Server_Start_Timeout, (see Creating a Connection to RTserver).

A backup RTclient can use the option Server_Msg_Send to receive incoming messages but not send any outgoing messages (see Sending Messages).

RTserver can reconnect to other RTservers if an error occurs (see Reconnecting to Other RTserver Processes).

Dynamic message routing handles many network failures, such as rerouting around RTservers that fail (see Dynamic Message Routing).

Load balancing enables publish-subscribe to have redundant RTclients for processing messages (see Load Balancing).

In addition to the above features, both RTclient and RTserver have several additional options that can be easily configured to add fault tolerance.

RTclient Options

In addition to the already mentioned fault tolerance features, these convenient options can be used to help RTclient check for network failures:

Server_Keep_Alive_Timeout — controls the keep alive timeout property of the connection to RTserver

Server_Read_Timeout — controls the read timeout property of the connection to RTserver

Server_Write_Timeout — controls the write timeout property of the connection to RTserver

RTserver Options

In addition to the already mentioned fault tolerance features, these options can be used to help RTserver check for network failures:

Client_Connect_Timeout — controls how long RTserver waits when trying to read a CONNECT_CALL message from a new RTclient that has just connected

Client_Max_Buffer — controls how many bytes of data RTserver buffers for an RTclient before deciding the RTclient has failed (this is needed instead of keep alives because RTclient is not required to process messages from RTserver at regular intervals)

Server_Connect_Timeout — controls how long RTserver waits when trying to read a SRV_CONNECT_CALL message from a new RTserver process that has just connected

Server_Keep_Alive_Timeout — controls the keep alive timeout property of the connections to other RTservers

Server_Read_Timeout — controls the read timeout property of the connections to other RTservers

Server_Reconnect_Interval — controls the rate at which RTserver tries to reconnect to other RTservers