Three Models Are Supported
General
The following connection establishment scenarios are supported:
Active client to passive server.
Active client to active client (referred to as a peer-to-peer operation).
Active client to passive server (with a third-party redirector).
The three subsections that follow provide a description of each of the three scenarios.
Active Client to Passive Server
This the most straightforward scenario (see Figure 36-1 on page 1075) and it was described in the numbered list under “Definition of Client and Server” on page 1110.
Active Client to Active Client
Introduction
In this scenario, two CMs, on behalf of their respective client applications, simultaneously initiate connection establishment request. There are actually two variants of this scenario:
The ServiceIDs in the two REQ MADs are different.
The ServiceID is the same in both of the REQ MADs.
Scenario 1: Different ServiceID in Two REQ MADs
In scenario one, upon receipt of the REQ MAD, each of the two CMs will treat this as a normal active client to passive server connection request (as shown in Figure 36-1 on page 1075). Each of the CMs plays the active role (REQ/RTU sender) for the request it initiated and the passive role (REP sender) for the request initiated by the other CM. The end result is that two separate communications channels are created between the two client/server pairs.
Scenario 2: Same ServiceID in Two REQ MADs
The Situation
In scenario two, the ServiceIDs in the two simultaneous REQ messages are identical, indicating that two applications that provide the same service are attempting to communicate with each other. Rather than creating two separate communications channels, the CMs should only create a single QP on each end to connect the identical services to each other.
Refer to Figure 36-3 on page 1114. In this situation, both CMs have started out in the active role by issuing a REQ MAD. However, one of them is going to have to switch to the passive role, sending the REP MAD and receiving the RTU MAD.
Figure 36-3. Peer-to-Peer With Same ServiceID
The Resolution
The situation is resolved as follows:
Both of the CMs provided the GUID of their respective CA in the REQ MAD (see the description of the Local CA GUID field in Table 36-4 on page 1075).
Each CM compares the GUID of its local CA to the GUID of the remote CA. The CM whose CA has the numerically smaller GUID assumes the passive role, returning the REP MAD and then awaiting receipt of the RTU MAD.
If their respective GUIDs are the same, then both REQ MADs were sent by the same CM (and therefore by the same CA). A loopback such as this on a CA is permitted, but creating a loopback communications channel from the SQ to the RQ on a single QP is not.
In the case where the CA GUIDs are the same, the CM then compares the QPNs supplied in the two REQ MADs (treating each as a big-endian value) to determine which of the two communications establishment processes will take the passive role. The one that issued the REQ MAD with the numerically smaller QPN takes the passive role.
Active Client to Passive Server with Third-party Redirector
Either due to the author's diminished mental capacity this far along in the writing of this book, or due to a need for clarification in the specification (or both), the author finds himself unable to clearly understand this concept. It sounds like normal redirection of a General Service, but the fact that the specification writers have singled it out for special treatment is puzzling. For this reason, the specification text describing this aspect of CM (and the illustration from the specification—see Figure 36-4 on page 1115) is provided verbatim here:
A redirector is a CM that provides CM services on behalf of an entity supported on a port other than the redirector CM's port. The port information for both endpoints is explicit in the REQ and REP messages, allowing the redirector to manage connections as a proxy for another entity. The above exchange occurs when the redirector sends REJ with the Status “Port Redirection,” indicating that the requested ServiceID is available at a different port. The requesting client (using a new Local Communication ID) sends a new REQ proposing the port specified in the REJ. All CM messages are exchanged between the client CM and the redirector, but traffic over the established connection goes between the client and the server.
Figure 36-4. Active Client to Passive Server with Third-Party Redirector
