Tibco不可多得的内部培训资料.doc

TIBCOs information bus (TIB)一、introduction= Examples of Valid Subject Names: = 1. NEWS.NATIONAL.ARTS.MOVIES.REVIEWS 2. CHAT.DEVELOPMENT.BIG_PROJECT.DESIGN 3. News.Sports.Baseball 4. finance 5. Long.subject_name.is.valid.even.though.quite.uninformative= Examples of INVALID Subject Names: = News.Natural_Disasters.Flood - Invalid null element in subject string WRONG. - Invalid null element at the end of the subject string .TRIPLE.WRONG. Invalid subject string with three null elements= Reserved Names = _INBOX. - Inboxes are subject names used for point-to-point message delivery - All system generated inbox names begin with this prefix _LOCAL. - Subject names with this prefix are local to the TIBCO Rendezvous daemon - These messages do not reach the network _RV. - Subject names with this prefix are TIBCO Rendezvous advisory messages _RVCM. - Subject names with this prefix indicate internal administrative messages associated with certified message delivery - Application programs must not send to subjects with this prefix_RVFT. - Subject names with this prefix indicate internal administrative messages associated with TIBCO Rendezvous fault tolerance software - Application programs must not send to subjects with this prefixPublish/subscribe messages are like radio broadcasts; the sender picks a frequency, and any listener who tunes to that frequency receives the broadcast. The broadcast subject name is analogous to a radio frequency. Any application that listens for a subject receives all messages bearing that subject name.The Rendezvous Daemon (rvd) is a runtime background process that implements TIBCO Reliable Datagram Protocol (TRDP). The daemon sends, listens for, filters and routes subject-based messages reliably, detects lost messages and requests re-transmission. Daemons can be started automatically or manually. The Rendezvous API supplies the message structure and communication type and passes messages to the daemon via a TCP connection. Usually a Rendezvous daemon is run on the same machine as the Rendezvous application but remote daemon connections are possible. Connection Stack In the above slide the various layers of the stack pass up traffic, but only if a higher layer has registered interest in some manner. The Network Interface Card (NIC) will only process network traffic which meets one of three criteria: - Own hardware address - Broadcast - Address contained on Multicast tableThe NIC Driver will process and forward traffic which is registered at the TCP/IP layerThe TCP/IP layer will only forward traffic which is routed to an open TCP/UDP port, e.g. 7500/UDP default for the TIBCO Rendezvous daemonThe TIBCO Rendezvous daemon will only forward traffic on which a connected consumer application has registered subject interest, and only after the complete message has been receivedTRDP is implemented by the TIBCO Rendezvous daemon (rvd). TRDP adds a sequence number to each outbound message packet. TRDP uses a buffer to store outbound messages for a specified interval. If a message packet is lost the consuming rvd requests retransmission. Buffer operations are private to the TRDP implementation; there is no API to access it.TRDP is optimistic: it assumes messages will arrive at their destination. Only if a message is lost will TRDP send a negative acknowledgement (NAK) requesting retransmission. Compare this with TCP which is pessimistic: explicit acknowledgment of each received message is required.The default buffer interval is 60 seconds and should not be increased. If stronger delivery assurance is required, Rendezvous certified (RVCM) messaging should be usedTIBCO Rendezvous Certified MessagingWhile standard Rendezvous communication is highly reliable, business requirements often dictate the need for even stronger assurance of message delivery. RVCM fulfills this need, guaranteeing the delivery of each message at its intended destination.Standard Rendezvous reliable subscribers can receive certified messages published on a subject that they have subscribed to. However, they will not participate in recovery attempts at the API level (as you will find detailed later in this unit). Automatic Discovery 1. CM listener receives a CM message, it detects this because such a message has two additional labels: - The name of the CM sender - The sequence number for the message within the CM interaction; this sequence number will be set to 0 (by the CM API at the subscriber) until a full certified delivery agreement has been established (see below) 2. The CM listener records the CM sender name and subject name in its ledger file. 3. The CM listener sends a request for registration to the CM sender. 4. The CM sender receives the request for registration and will decide whether it accepts the registration (it can be instructed to reject all registration requests from this subscriber). - If it rejects the request, it will inform the listener and no Certified Delivery agreement will have been established. - If it accepts the request, it will record the listener in its ledger file and any subsequent message(s) will be recorded in the ledger file and require acknowledgement from the subscriber.5. The certified sender explicitly informs the certified listener of the acceptance, which completes the Certified Delivery agreement. We refer to the two CM transports that participate in a certified delivery agreement as a certified sender and a certified listener, and the labeled messages that flow between them are certified messages. Notice the subtle difference in terminologybefore establishing a certified delivery agreement, the participating transports are CM senders and CM listeners; afterward, they are certified senders and certified listeners. Similarly, a labeled message becomes a certified message only when the sender and receiver maintain a certified delivery agreement.Certified Message Structure An RVCM message contains three additional fields that are added to the message. These are: 1. The correspondent name of the CM transport that sent the message. 2. A sequence number assigned by the sending CM transport. 3. A time limit, after which the sending program no longer expects its CM transport to certify delivery of the message.Depending on your design, the CM transport name can be persistent (name generated and reused by you) or non-persistent (automatically generated by the CM API)Routing Daemon OperationsRendezvous routing daemons (rvrd) forward messages between networks. Each rvrd contains one or more software routers. Each software router connects one or more local networks with one or more other software routers. Each rvrd builds a representation of the whole network and can select an optimal route. Each software router will only allow specified subjects to be imported and exported to reduce network load and to increase security. Each rvrd registers interest (subject names that subscribers have registered with Rendezvous daemons) on the local network and passes that information to neighbors. Thus, messages will only be sent to networks where there is at least one active subscriber. Whereas rvd delivers messages to applications on computers within a single network, an rvrd delivers messages beyond network boundaries. Rendezvous routing daemons efficiently connect applications on separate IP networks so that messages flow among them as if on a single network. Rendezvous routing daemons forward messages between networks, allowing applications on one network to listen for and receive messages from applications other networks. Rendezvous routing daemon administrators control with subject names the messages that can traverse their networks. An rvrd subsumes rvd functionality, so it is not necessary to run both on the same host.Load BalancingIn the above example, the administrator has specified that G imports foo. with weight 1 (retaining the default weight), and bar. with weight 10. Conversely, H imports foo. with weight 10, and bar. with weight 1. When all the components operate properly, messages with subjects foo. travel through F and H, while messages with subjects bar. travel through E and G. If E were to fail, all messages would travel through F and H (because that route has the lowest path cost).TIBCO Rendezvous Fault Tolerance TIBCO Rendezvous Fault Tolerance (RVFT) coordinates a set of concurrent processes within a group of FT members. A FT group is a set of application processes that cooperate for fault tolerant services. An RVFT group can have any number of members. New members can join and existing members can leave FT groups at any time. Processes can be members of more than one FT group. More than one FT group can exist on the same network. FT group names, therefore, must be unique.In this example, four applications in the FT group Acme.FT.Group cooperate to broadcast Rendezvous messages. The Active Goal is 1, meaning only one application will actively publish data. Application A, with a weight of 20 (highest in the group), is the Active member (the actual publisher). The other members process the same information stream but do not publish. They also listen for heartbeats from the Active member. The ranking inactive member is next in line to take over publishing should the Active member fail or exit.=Heartbeats=Each Active member publishes a heartbeat to all other members it its FT group. A heartbeat produces a regular, periodic stream of Rendezvous messages indicating that the Active member is alive, i.e., actively processing the required task(s). All inactive members in the FT group subscribe to the Active members heartbeat message. If inactive processes fail to hear the Active members heartbeat within a specified interval, the Ranking Inactive member will take over processing.Any number of Rendezvous applications that are not members of the FT group can be used to passively monitor the heartbeats of active members in an FT group. Such passive monitors have no influence on the FT group or its members, and members do not know that they are being monitored by applications outside the group.It is important to clarify what we mean by active and inactive. All the API does is to call a user function or method with a parameter indicating what the new state of the application should be. It is up to the application to specify what the appropriate behavior is to become active or inactive.= Several parameters are used to dictate and manage RVFT group and member behavior, including: =- FT Group Name is the attribute that binds members of a group together. Applications can join as many groups as they like using different group names. If an application joins the same group twice, results are undefined.- Active goal is the number of active members specified by the design of the FT group. Any number of members may be active in an FT group. RVFT will automatically activate and deactivate members to ensure that the active goal is met. If it cannot be met, advisory messages will be published. Each member MUST specify exactly the same active goal as the other members. Differences may result in erratic behavior with members alternating rapidly between becoming activate and inactivate.- Member weight specifies the ability of the application to complete assigned tasks, relative to other members in the FT group. When a process joins a FT group it specifies its weight. Member weight is used to determine member rank, which in turn is used to determine Active member status1. Member rank is a unique number assigned to each FT group member. To determine rank (and, therefore, active and inactive status), RVFT sorts members according to their weight. The member with the highest weight receives the rank of 1, indicating that it outranks all other members. Members with the next highest weight receive a rank of 2, and so on. Therefore, a member with a rank of n takes precedence over a member with rank n + 1. In case of a tie (members with the same weight), RVFT determines the rank based on seniority. Members of higher weight always outrank members of lower weight. Note that weight signifies processing capacity, meaning hardware and operating system capabilities must be carefully considered when assigning weight to members. RVFT applications can be programmed to adjust their weight dynamically at any time. RVFT will automatically recalculate member rank accordingly anytime a members weight changes.2. Each RVFT group member must specify a heartbeat interval. This interval is used to determine the interval at which an active member will publish its heartbeat message. 1) The activation interval is the interval that an inactive member waits before becoming active when a heartbeat signal is lost. When a process joins a fault-tolerance group, it specifies its activation interval. All members of a FT group must specify the same activation interval. 2) When process joins an FT group, it may specify a preparation interval. This parameter specifies how long an inactive member needs to prepare before becoming active. If its value is 0, no prep time will be allowed. It might be used to allow an application some time to connect e.g. to a database to speed up the final activation process. It will be asked to become active only after the activation interval has expired.= RVFT in Action = With these intervals in mind, lets revisit the RVFT Operations diagram and consider the sequence of events should Application A go down. Inactive members track heartbeat messages from each active member. When the time since the last heartbeat from an active member reaches this activation interval, Rendezvous fault tolerance software instructs the ranking inactive member to activate - in this case Application B. (Note that the preparation interval must also be adhered to if this parameter has been specified.)Once active, Application B begins publishing data as well as heartbeat signals. Since the remaining two members have the same weight, RVFT breaks the tie and assigns ranking inactive status to the member with more seniority (Application C). Application D remains inactive, and all three functioning applications continue to cooperate in the FT group.TIBCO Rendezvous Distributed Queu