|
|
|
|
|
|
Setting Up Selective Broadcasting
Selective broadcasting enables applications to send messages to multiple destinations using a single program call. This chapter discusses the following topics:
Overview of Selective Broadcasting
BEA MessageQ Selective Broadcast Services (SBS) enable applications to send a message to many receiver programs using a single program call. The sender program uses the standard pams_put_msg service to send a message to a set of queues registered to receive broadcast messages. The SBS Server also maintains the queue availability database used by the AVAIL/UNAVAIL services.
BEA MessageQ for OpenVMS includes the following SBS features:
Note: In version 4.0A and version 5.0 of BEA MessageQ for OpenVMS, SBS includes a set of message-based services which obsoletes the message interfaces used in version 3.2B and prior versions. However, applications that currently use the prior versions of SBS will continue to run in a version 4.0A or version 5.0 BEA MessageQ for OpenVMS environment. The older, obsolete, message interfaces are not supported on non-OpenVMS SBS platforms such as UNIX or Windows NT.
The BEA MessageQ SBS Server must be running for applications to use either the Selective Broadcast or AVAIL/UNAVAIL services. To start the SBS Server for a message queuing group, edit the Profile section of the DMQ$INIT.TXT file and set the symbol ENABLE_SBS set to YES, and then start the message queuing group. The ENABLE_SBS parameter is set to YES by default in the group initialization file template supplied with BEA MessageQ for OpenVMS. Listing 6-1 shows the ENABLE_SBS parameter in the Profile section of the group initialization file.
Listing 6-1 SBS Enable Parameter
%PROFILE ***** Profile Parameters *****
*
...
ENABLE_MRS YES ! Enable MessageQ Message Recovery Services
ENABLE_JRN YES ! Enable MessageQ Message Journaling Services
ENABLE_SBS YES ! Enable MessageQ Selective Broadcast Services
...
*
%EOS
Configuring Broadcasting
Use the SBS Server initialization section of DMQ$INIT.TXT to configure the broadcasting operation of the local SBS Server. This section of DMQ$INIT.TXT begins with %SBS.
This section covers the following information:
Specifying Multipoint Outbound Target (MOT) Addresses
A Multipoint Outbound Target (MOT) is a queue address that is associated with a broadcast stream capable of broadcasting a single message to multiple target queues. MOT addresses are divided into two ranges, PRIVATE and UNIVERSAL. Messages sent to PRIVATE MOTs are broadcast only within the local group; they are not transmitted to other SBS servers. Messages sent to UNIVERAL MOTs are broadcast to the local group as well as to all SBS servers connected to the BEA MessageQ bus. For UNIVERAL MOTs, a single broadcast message is sent to each remote SBS, then each SBS server broadcasts them locally to all interested target queues.
The PRIVATE range includes addresses from MOT_PRIVATE to MOT_RESERVED -1. BEA MessageQ broadcasts messages within the PRIVATE range using a list maintained by the local SBS Server.
The UNIVERSAL range includes addresses from MOT_RESERVED to MOT_UNIVERSAL. BEA MessageQ broadcasts messages within the UNIVERSAL range to all SBS servers on the message queuing bus and then each SBS server broadcasts them locally to all interested target queues.
MOT_PRIVATE, MOT_RESERVED, and MOT_UNIVERSAL are defined in Table 6-1
Table 6-1 %SBS MOT Address Ranges
|
Parameter |
Address |
Description |
|
MOT_PRIVATE |
4000 |
Private MOT address are in the range of 4000-4900, inclusive. Messages broadcast to these address will remain local to the queuing group. |
|
MOT_RESERVED |
5000 |
MOT address settings 4901 to 5099 are reserved for BEA MessageQ. |
|
MOT_UNIVERSAL |
6000 |
Universal MOT address are in the range of 5100-5999, inclusive. Messages broadcast to these addresses will be transmitted outside the queuing group. |
Note: MOT ranges 4901 to 4999 and 5000 to 5099 are reserved for BEA MessageQ.
Configuring Optimized Ethernet Mode
The optimized Ethernet mode on the SBS server utilizes the hardware multicasting available with Ethernet controllers. Therefore, instead of simulating broadcasting by sending a message to each adjacent SBS server over the standard BEA MessageQ links, it broadcasts one message to all listening systems on the bus. This mode has an advantage of scalability whereby any number of receiver systems can receive the same BEA MessageQ messages.
Listing 6-2 shows the SBS Server initialization section of the group initialization file template.
Listing 6-2 %SBS Initialization File Section
%SBS ******* SBS Server Initialization Section ************
*
* NOTE: Heartbeat interval is in units of 1 millisecond
*
HEARTBEAT 2000 ! default is 1 second
*
* ---- Service ----
* ID Prot/Xport
COMM_SERVICE 10 DG/DMQ ! default emulated broadcast path
GROUPS * ! all known server groups
REGISTER * ! all universal MOTs
END_COMM_SERVICE
*
* ---- Service ----
* ID Prot/Xport
COMM_SERVICE 0 DG_OLD/ETH ! datagram messaging over optimized Ethernet
DEVICE_1 ESA0: ! VMS device name of the Ethernet board (rail A)
DEVICE_2 EZA0: ! VMS device name of the Ethernet board (rail B)
DRIVER_BUFFERS 16 ! # of VMS Ethernet driver buffers to preallocate[10-255]
*
* < <<<<<<<<<<<<<<<<< Warning >>>>>>>>>>>>>>>>>>>
* The protocol and Ethernet addresses show below are not registered
* and are not guaranteed to be conflict free. Use them with discretion.
* |------ MCA ----| |Prot #|
CNTRL_CHAN AB-AA-34-56-78-90 81F0 74
DATA_CHAN AB-12-34-56-78-91 81F1 75
*
* NOTE: MAB = Message Assembly Buffer. Each MAB requires area for
* a large message buffer, plus overhead of 150 bytes.
*
* Default Default Heartbeat
* Transmit SILO Receive SILO Maximum Poll Dead Poll
* MOT (in MABs) (in MABs) Heartbeat Interval Interval
REGISTER 5101 1 5 4 10 10
REGISTER 5102 1 5 4 10 10
REGISTER 5156 1 5 6 10 10
*
END_COMM_SERVICE
*
* ---- Service ----
* ID Prot/Xport
COMM_SERVICE 0 RP/ETH ! retransmission protocol over optimized Ethernet
DEVICE_1 ESA0: ! VMS device name of the Ethernet board (rail A)
DEVICE_2 EZA0: ! VMS device name of the Ethernet board (rail B)
DRIVER_BUFFERS 16 ! # of VMS Ethernet driver buffers to preallocate[10-255]
*
* < <<<<<<<<<<<<<<<<< Warning >>>>>>>>>>>>>>>>>>>
* The protocol and Ethernet addresses show below are not registered
* and are not guaranteed to be conflict free. Use them with discretion.
* |------ MCA ----| |Prot #| |UCB #|
CNTRL_CHAN AB-AA-34-56-78-90 81F0 74
DATA_CHAN AB-12-34-56-78-90 81F2 76
*
* NOTE: MAB = Message Assembly Buffer. Each MAB requires area for
* a large message buffer, plus overhead of 150 bytes.
*
* Default Default Heartbeat
* Transmit SILO Receive SILO Maximum Poll Dead Poll
* MOT (in MABs) (in MABs) Heartbeat Interval Interval
REGISTER 5104 30 15 4 10 10
REGISTER 5105 10 6 4 10 10
*
END_COMM_SERVICE
*
%EOS
Table 6-2 describes the parameters in the SBS Server initialization table.
Note: There is a convert utility to help you migrate your earlier, existing DMQ$INIT files into the new COMM_SERVICE format. See the BEA MessageQ Installation Guide for OpenVMS for information on conversion.
Table 6-2 %SBS Section Parameters
|
Parameter |
Description |
|
HEARTBEAT |
A numeric field which specifies granularity of the heartbeat timer that is used to detect sequence gaps and lost packets. The timer is measured in one millisecond units. The default is 2000 or two seconds. This value is used by the recovery protocol in conjunction with the poll and dead poll interval described below. |
|
COMM_SERVICE |
A two-field record. The first field is a unique integer between 0 and 10 that indicates which communication service is being defined. (Starting with BEA MessageQ v4.0A, the only services available are 0-10.) The COMM_SERVICE number is intended to be used to control the priority of one path over another when multiple paths to a group are detected. The lower the number the higher the priority. Services 1-9 are optional and correspond to the old DMQ$INIT Ethernet SET command numbers. Service 10 is reserved for the default unoptimized BEA MessageQ broadcasting, must be set to the DMQ transport at this time. The second field indicates the method of server-to-server communications this service uses. The first part is the protocol type and the second is the transport type. The two parts must be separated with a / (slash) character. |
|
Protocols |
|
|
Transports |
|
|
GROUPS |
A numeric field that contains a single BEA MessageQ group number per line. Used to indicate which groups should be broadcasted to. Starting with BEA MessageQ version 4.0A the required setting is an asterisk (*), used to indicate all known groups. This keyword is only useful when BEA MessageQ is used as a transport. The default is *. |
|
DEVICE_1 |
A text field that specifies the name of the Ethernet controller to use for each rail. Single-rail configurations use the DEVICE_1 keyword only; dual-rail configurations use both. This keyword is useful only in conjunction with the Ethernet transport. In a given initialization file, only one setting may be entered for DEVICE_1/DEVICE_2. If multiple settings are entered, only the last will be used. |
|
DRIVER_BUFFERS |
A numeric field that contains the number of buffers that the system Ethernet controller should use to buffer incoming packets. On OpenVMS, this directly affects the amount of non-paged pool allocated to each channel by the Ethernet controller. The default is 16. In a given initialization file, only one setting may be entered. If multiple settings are entered, only the last will be used. |
|
CNTRL_CHAN |
A three-field record that specifies the Ethernet protocol/address pair for control information. The first field identifies the Ethernet hexadecimal multicast address (the low-order bit of the first byte must be set) that the SBS Server uses in the Ethernet transport mode. The second hexadecimal field is a unique protocol number used by the SBS Servers. The address/protocol pair for the SBS control channel must be consistent in all cooperating SBS Servers and must be distinguishable from other address/protocol pairs (for example, LAT, DECnet, local area VMSclusters, and so on). |
|
DATA_CHAN |
A two-field record that specifies the data channel for optimized communications. The address/protocol pair for the SBS data channel must be consistent in all cooperating SBS Servers and must be distinguishable from other address/protocol pairs (for example, LAT, DECnet, local area VMSclusters, and so on). The first field is the hexadecimal Ethernet multicast address in the form of XX-XX-XX-XX-XX-XX. The second field is the hexadecimal Ethernet protocol number. |
|
REGISTER |
A one-field or six-field record used to add a subscription ID (MOT) to the communication service. The number of fields depends on the type of service being specified. For DG/DMQ it is a one-field record; all others are six-field. |
|
MOT |
Subscription ID that identifies the unique broadcast stream. For datagram protocols using the DMQ transport, a wildcard character (*) can be used to indicate all possible subscription IDs. Make sure you record the number of MABs a given Subscription ID has because it has direct effect on the total amount of virtual memory that the SBS Server uses. |
|
Transmit Silo |
Number of Message Assembly Buffers (MABs) used to manage retransmission requests. For Datagram protocols this will always be forced to one. Valid ranges 0 to 100. |
|
Receive Silo |
Number of MABs to use for simultaneous multi-packet receptions. Valid ranges 0 to 100. For DG_OLD protocols this will always be forced to 5. |
|
Maximum Heartbeat |
Number of unacknowledged Polls before a sender is considered dead. Valid ranges 0 to 100. |
|
Poll Interval |
Number of MOT heartbeat intervals without an intervening message before a poll request is generated. Valid range is 0 to 100. |
|
Dead Poll Interval |
Used as a multiplier to the Poll Interval to reduce the number of Polls sent to an unresponsive or inactive group. Valid range is 0 to 100. |
|
END_COMM_SERVICE |
Keyword used to close a communication service description block. |
Listing 6-3 shows the Ethernet Broadcasting Parameter Settings in the Queue Configuration Table (QCT) section of the group initialization file.
Listing 6-3 Ethernet Broadcasting Parameters in %QCT Initialization File Section
%QCT ***** Queue Configuration Table ******
*
* ---Pool Quota--- UCB Q Q Confrm Perm Name Chk
* Queue Name Num Bytes Msgs Ctrl Send Type Own Style Act Scope ACL
*------------------- ---- ------- ---- ---- ---- ---- ---- ----- ---- ----- ----
...
*
* SBS Server uses the following UCB numbers for Optimized Delivery
*
SBS_ETH_CONTROL 74 0 0 . E . . . . L N
SBS_ETH_CHAN1 75 0 0 . E . . . . L N
SBS_ETH_CHAN2 76 0 0 . E . . . . L N
*
...
%EOS
The queue configuration table (%QCT) section of the DMQ$INIT.TXT file must contain entries for the CNTRL_CHAN and each of the DATA_CHAN entries. These entries must correspond to the correct queue address, have zero quota, and have the E flag set in the UCB Send field.
Broadcasting Requirements and Restrictions
A registry of reserved protocols and multicast addresses is maintained by the Xerox Corporation. Choose protocols and multicast addresses so that they do not conflict with other users of the local area network (LAN). See Chapter 9 of the OpenVMS I/O User's Reference Manual.
The following are requirements and restrictions imposed on SBS:
The following list describes the supported interoperability between versions and platforms running the SBS Server in BEA MessageQ for OpenVMS V5.0:
Ethernet Broadcast Recovery Methods
The BEA MessageQ for OpenVMS SBS Server incorporates an Ethernet retransmission protocol which allows the automatic recovery of lost message packets. A receiving SBS Server can request lost message packet retransmissions up to a selectable depth of message packets.
This feature allows the SBS Server to attempt to recover lost messages identified by a sequence gap. This feature, combined with dual-rail support, significantly enhances the reliability of optimized Ethernet broadcasting.
Configuring Optimized Ethernet Mode
The optimized Ethernet mode on the SBS Server uses the hardware multicasting available with Ethernet controllers. Instead of simulating broadcasting by sending a message to each adjacent SBS Server over the standard BEA MessageQ links, it broadcasts one message to all listening systems on the bus. This mode has the advantage of scalability: a single copy of a message is transmitted across the network and is received only by those systems which have applications registered for the message's MOT. Therefore, this facility improves network utilization by limiting the traffic per message placed on the network.
Because messages sent via direct Ethernet access are limited to 1,500 bytes, the sending and receiving SBS Servers handle segment and reassemble the messages. This segmentation, coupled with network load, increases the probability that a packet collision may result in a lost packet at one or more receiver systems. A lost packet, in turn, results in a lost message, which is reported to receiving applications as a broadcast sequence gap.
Note: Although BEA MessageQ supports message sizes up to 4MB, optimized Ethernet mode limits message sizes to 32,000 bytes.
In the following discussion, refer to Listing 6-2, which shows the SBS Server initialization section of the group initialization file template, as well as Table 6-2, which describes parameters and fields.
Dual-rail Mode
BEA MessageQ provides two features to increase the reliability of messages sent using Optimized Ethernet Mode, dual-rail mode and the RP/ETH retransmission protocol. With dual-rail mode, SBS supports up to two (2) Ethernet devices per system. Using two Ethernet devices decreases the chance that a lost packet resulting from a network collision will result in a lost message. The sending system writes a copy of the message to the devices specified in the DEVICE_1 and DEVICE_2 parameters for COMM_SERVICE with a value of DG_OLD. Receiving SBS Servers construct a single copy of the message from packets received from both Ethernet devices. If a packet contained in a particular message is not received from either rail, a sequence gap message is sent to receiving applications that requested sequence gap notification.
To configure dual-rail mode, specify the Prot/Xport field of the COMM_SERVICE as DG_OLD. Specify valid device addresses for both Ethernet devices on your systems, insuring that you specify device unit 0 (for example, ECA0: or EWB0:). Ensure that the Ethernet devices specified in the DEVICE_1 and DEVICE_2 fields of various groups are actually connected on the same network. The simplest method is to build single-rail configurations for all groups (specify only DEVICE_1) and use the DMQ$EXE:DMQ$SBS_EXAMPLE program to verify broadcast reception in each group. Repeat this test using the devices specified for DEVICE_2 as DEVICE_1 to ensure that the final dual-rail configuration is properly configured.
The only field in the REGISTER line that is specified by the user with this service is the MOT. The transmit and receive silos are forced to their default values of 1 and 5, respectively; the heartbeat parameters do not affect this service.
RP/ETH Retransmission Protocol
There are some applications where broadcast messages need a higher probability of delivery than is provided by simple dual-rail redundancy. SBS provides the RP/ETH retransmission protocol by which a receiving SBS Server that cannot construct a complete message may request it from the sending SBS Server. If the sender still has the message in its cache, it will resend it to requesting system.
It is important to understand that the retransmission protocol is not a recoverable delivery protocol. That is, messages sent to a MOT whose COMM_SERVICE is the retransmission protocol (RP/ETH) may still result in sequence gap at one or more receiver systems. This protocol is best suited to broadcast traffic with a predictable delivery rate.
The RP/ETH communication service operates as follows. Any message sent to a MOT whose service is RP/ETH are placed in a cache called the transmit silo after they are sent. The transmit silo size is measured in Message Assembly Buffers (MABs). Each MAB contains a complete copy of the largest message (up to 32,000 bytes) that this queuing group can send or receive. MABs also contain sequencing information used to control retransmission requests. Transmit silos are first-in/first-out: the oldest message in the transmit silo is removed when a new message requires storage. The transmit silo size is specified by the Transmit Silo parameter in the REGISTER statement used to define the MOT.
If a missing segment is detected by a receiving SBS Server, it requests retransmission of the message from the point at which the first missing segment was detected. This request is sent via a high-priority message (transmitted via the standard BEA MessageQ cross-group transport, either TCP/IP or DECnet) to the sending SBS server. The requested message fragment (or an entire message) is returned via a high-priority message, which is also transmitted via the standard BEA MessageQ cross-group transport. If the message has already been flushed from the sending group's transmit silo, a sequence gap notification is delivered to the receiving applications.
Each MOT using RP/ETH also has a receiver cache called the receive silo. The receive silo accumulates messages to ensure in-order delivery to registered applications. For example, a sender broadcasts messages 46, 47 and 48 to an RP/ETH MOT but the receiver receives only messages 46 and 48. It is necessary for the receiving system to hold message 48 until the retransmitted copy of message 47 is received. Receive silo size is also measured in MABs. The receive silo size is specified by the Receive Silo parameter in the REGISTER statement used to define the MOT.
RP/ETH Receive Silo Rules
Receive silos are emptied according to the following rules:
RP/ETH Examples
SBS Servers using optimized Ethernet provide timely detection of missing messages. Consider the case where a sending group broadcasts message 26, which is short enough to be contained in a single packet. Assume that a receiving group does not receive this packet due to a network collision. The receiving group does not detect that it missed message 26 until message 27 is broadcast. To prevent this condition, SBS Servers using RP/ETH protocol exchange status inquiries on a periodic basis. The minimum interval between these inquiries is called the heartbeat and is specified in 1 millisecond units. Thus, if the heartbeat parameter were set to 1000, status polling exchange occurs no more than once per second. The HEARTBEAT statement specifies this value for a particular group.
Recognizing that MOTs may vary with respect to their expected traffic rates, BEA MessageQ allows you to control the polling on a per-MOT basis. It does so with three parameters specified for the MOT in a REGISTER statement: maximum heartbeat, poll interval and dead poll interval. These values are multiples of the heartbeat specified for the group. Thus, if the heartbeat were set to 2000 (that is, 2 seconds) and the poll interval were set to 2, the actions associated with the poll interval would be executed after 4 seconds had elapsed. The following example shows how these parameters interact.
Assume that you have 2 groups, 30 and 31, using RP/ETH for MOT 5101. To simplify things, assume that group 30 only sends broadcast messages and group 31 only receives these messages. The relevant parameters in the SBS section in group 31's initialization file are:
HEARTBEAT 1000
COMM_SERVICE 0 RP/ETH
! Transmit silo Recv silo Max HB Poll Dead Poll
REGISTER 5101 10 10 4 5 10
The following sequence of operations occurs:
RP/ETH Configuration
Using RP/ETH protocol is most effective if you limit its use to a small number of MOTs that have predictable traffic patterns. Specify the Prot/Xport field of the COMM_SERVICE as RP/ETH. Specify valid device addresses for both Ethernet devices on your systems, ensuring that you specify device unit 0 (for example, ECA0: or EWB0:). Ensure that the Ethernet devices specified in the DEVICE_1 and DEVICE_2 fields of various groups are actually connected on the same network. The simplest method for ensuring this is to build single-rail configurations for all groups (that is, just specify DEVICE_1) and use the DMQ$EXE:DMQ$SBS_EXAMPLE program to verify broadcast reception in each group. Repeat this test using the devices specified for DEVICE_2 as DEVICE_1 to ensure that the final dual-rail configuration is properly configured.
Set all parameters on the REGISTER line for each MOT to RP/ETH. Sending groups should specify more Transmit Silo MABs, and Receiving Groups should specifiy more Receive Silo MABs, thereby increasing the likelihood of retransmission requests being fuilfilled. Note that each MAB requires a buffer equal to the size of the group's maximum message (up to 32,000 bytes) plus 150 bytes, so you should expect to increase the PGFLQUO parameter in SBS Section of DMQ$USER:SET_SERVER_QUOTAS.COM to reflect this increased virtual memory demand.
Tuning this service is an iterative process. There are message-based API calls which allow you to retrieve statistics for traffic and retransmission activity by MOT. See the sbs_status_req and sbs_status_resp messages in the BEA MessageQ Programmer's Guide for more information.
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|