Overlapping Subject Space

Consider two distinct distributed programs that use overlapping subject spaces—that is, they use some of the same subjects for their messages. When the two programs are deployed on the same physical network, each one receives messages from the other, which is inappropriate. To eliminate interference within the network, isolate each program to a separate UDP service.

Yet this solution within one network does not ordinarily keep the subject spaces separate when routing daemons connect two or more networks, because the routing daemon merges the subject spaces of its local networks.

Figure 61: Routing Daemons Merge Subject Spaces

For example, on the left side of Routing Daemons Merge Subject Spaces, the two UDP services 7500 and 7502 effectively separate one physical network (K.foo.com) into two disjoint subject spaces; that is, program L2 cannot receive messages from program S1. Similarly, on the right side of Routing Daemons Merge Subject Spaces, two UDP services 7577 and 7588 effectively separate one physical network (J.foo.com) into two disjoint subject spaces. However, the routing daemons in this configuration merge the subject spaces of their local networks—effectively canceling the separation; that is, program L2 does receive messages from program S1.

To restore the separation, configure an independent routing table entry for each local network, as in Independent Routing Table Entries Keep Subject Spaces Separate.

Figure 62: Independent Routing Table Entries Keep Subject Spaces Separate

In Independent Routing Table Entries Keep Subject Spaces Separate, each rvrd process contains two independent routers, which act as parts of two disjoint routes—keeping the data and subject spaces separate:

Routing table entries A and F form a route connecting network 2 with network 3.
Routing table entries B and G form a route connecting network 1 with network 4.

Notice that once again, program L2 cannot receive messages from S1.