Connections Unravel Substreams
Connections capture fine-grained monitoring metrics about message substreams within a transport. You can use connection metrics to analyze communication patterns and to diagnose network problems.
Programs and administrators cannot access or manipulate connections.
Conceptually, you can think of a connection as if it were one side of a miniature TCP connection within a transport, either the sending or receiving side.
As publishers and subscribers establish a transport bus, or join an existing bus, FTL software creates connection objects to gather operational metrics. Each connection object represents a message substream.
TCP Connections Example
- Program A creates a publisher, P, and program B creates a subscriber, S1, and together they establish a TCP transport bus.
The monitoring layer opens a connection object at each side to gather metrics. Connection A.P.1 represents the sending side, and connection B.S.1 represents the receiving side.
- Program B creates another subscriber, S2, with a different content matcher, and it joins the existing TCP bus.
The monitoring layer opens another set of connection objects. Connection A.P.2 represents the sending side, and connection B.S.2 represents the receiving side. Now one connection represents each subscriber within the transport in program B. However, two connections represent publisher P, one for each subscriber that receives messages from it (S1 and S2).
Even though a single TCP transport bus (orange line) carries the message stream between the two programs, the connection objects A.P.1 and A.P.2 separate the metrics for the two substreams (green arrows) outbound to the two subscribers. Moreover you can examine those substream metrics at either side of the network.
For simplicity, the diagram illustrates message flow in only one direction, even though connections monitor flow in both directions.
The same concepts apply to other transport protocols based on pair connections.
Multicast Connections Example
- Multicast Send A multicast send connection represents the message substream from a single publisher on a multicast transport.
Unlike the TCP example, a multicast send connection cannot separately measure its outbound substreams to different subscribers. However, if a sending program creates multiple publishers on a multicast transport, the monitoring layer measures the substream from each publisher with a separate multicast send connection (green MSConn connections).
- Multicast Receive A multicast receive connection represents the message substream into a subscriber from one specific publisher on a multicast transport (that is, one multicast send connection).
A subscriber that joins a multicast transport bus could receive many substreams from multiple publishers on that transport. A separate multicast receive connection gathers metrics corresponding to each substream (green MRConn connections).
- RUDP When a multicast transport enables the send inbox ability or receive inbox ability, RUDP connections represent the inbox substreams between each multicast sender and each of its receivers (pink RUConn connections).
As in the TCP example, a pair of unique connections measures each side of a substream.