Sample Configuration 2: tibsendex and tibrecvex

This second example illustrates basic concepts in configuring transports and endpoint implementation, namely: binding a transport to carry an ability, configuring connectors, joining endpoints through a common transport, dividing message streams over separate transports.

To clarify the concepts of endpoints and transports, consider the sample applications tibsendex and tibrecvex, and the sample realm configuration (see Sample Programs Reference).

  tibsendex tibrecvex
Program Description The sample program tibsendex creates a publisher object, and sends messages over its one-to-many send ability. The sample program tibrecvex creates a subscriber object, and receives messages over its one-to-many receive ability.
Endpoints The sample realm defines the application tibsendex with one endpoint (named tibsend-endpoint). The sample realm defines the application tibrecvex with one endpoint (named tibrecv-endpoint).

Default Application Instance

First consider the default application instance, and the effect of its configuration.

  tibsendex tibrecvex
Default Application Instance The sample realm configures the default application instance of tibsendex, implementing tibsend-endpoint with the transport shm-sendrecv-tport, which carries the endpoint’s one-to-many send ability. The sample realm configures the default application instance of tibrecvex, implementing tibrecv-endpoint with the transport shm-sendrecv-tport, which carries the endpoint’s one-to-many receive ability.
End Result Notice that the two application instances specify the same transport (shm-sendrecv-tport) to implement their respective endpoints. The effect is to join the two endpoints (tibsend-endpoint and tibrecv-endpoint) so that messages flow between them, from tibsendex to tibrecvex.

Another Application Instance

Next, consider another application instance, named mcast.

  tibsendex tibrecvex
mcast Application Instance The sample realm configures the mcast application instance of tibsendex, to match the identifier mcast. For matching processes, it implements tibsend-endpoint with the transport mcast-send-tport, which carries the endpoint’s one-to-many send ability. The sample realm configures the mcast application instance of tibrecvex, to match the identifier mcast. For matching processes, it implements tibrecv-endpoint with the transport mcast-recv-tport, which carries the endpoint’s one-to-many receive ability.
End Result Notice that the two application instances specify a pair of related transport definitions to implement their respective endpoints. Furthermore, those transport definitions are complementary, that is, the multicast send group of one is a multicast listen group of the other. The effect is to join the two endpoints (tibsend-endpoint and tibrecv-endpoint) with a single transport bus, so that messages flow between them, from tibsendex to tibrecvex.

If several process instances of tibsendex and tibrecvex were to run on networked host computers, their common transport bus would enable each instance of tibsendex to communicate with each instance of tibrecvex.

Note: However, messages do not flow between default application instances and mcast application instances. They use two different transport buses, which keep their message streams separate.
Related concepts