Transport Concepts
Transports are the underlying mechanisms that facilitate message communication among endpoint instances in programs.
TIBCO FTL software supports a variety of transport protocols. For descriptions, see Transport Protocol Types.
Inside a Transport
The following diagram presents a generalized view of transports and their operating roles.
Notice several aspects of this runtime perspective:
- Endpoint instances are objects within application processes. Application code uses API calls to create publisher and subscriber objects within application process instances.
- Transports are objects that straddle the edge of application processes.
Administrators configure transport definitions in the realm, and the TIBCO FTL base library expresses the transport definitions in application processes at runtime. These runtime transports act within the process to fulfill the transport’s two roles outside the process. That is, they establish a bus and serve as interfaces between endpoints and the bus.
- Transports and their operating details remain hidden from application code.
- The protocol type and details of the bus remain hidden from application code.
- The bus is conceptually outside the application processes. Transport objects mediate between the application program and the bus.
- Transport Definitions Must be Unique
It is erroneous to define two or more transports with identical transport configuration values. - Unitary and Fragmentary Transport Definitions
Transport definitions can be either unitary or fragmentary: - Bus Topologies
You can configure a set of cooperating transports to establish a bus with a predetermined topology. The following topics present configuration techniques for some example topologies. - Pair Connections
When defining connection-oriented transports (such as static TCP, RDMA, and RUDP) the connect end and the listen end must cooperate to establish a connection. - Subscriber Interest
Whenever possible, publishers send messages only to interested subscribers. That is, publishers send only those messages that match at least one subscriber content matcher. This behavior can reduce bandwidth consumption and can enhance subscriber performance in some situations. - Send: Blocking versus Non-Blocking
Administrators determine the behavior of send calls when a transport bus is full. Program developers may advise administrators concerning the correct behavior. - Inline Mode for Administrators
Programs that receive time-sensitive messages can use inline mode to favor low latency over high throughput. Inline mode reduces inbound message latency by consolidating transport I/O and message callback processing into one thread. - Receive Spin Limit
Receive spin limit is an advanced parameter of transports. If you understand the role of threads in inbound message delivery, you can use it to eliminate a potential source of latency by increasing the CPU resources dedicated to inbound delivery. - UDP Packet Send Limit
With UDP-based transports such as multicast, fast sending programs can overwhelm slower receiving programs, which could result in retransmission-related latency, extra resource consumption of CPU cycles and network bandwidth, retransmission storms, or data loss. To prevent these scenarios, you can limit the rate at which sending programs transmit UDP packets to the network.