Transport Concepts

Transports are the underlying mechanism that facilitate message communication among endpoint instances in programs.

TIBCO FTL software supports a variety of transport protocols. For descriptions, see Transport Protocol Types.

Transport Roles

Transports have two important runtime tasks:

  • Establish a bus, that is, a shared communication medium.
  • Serve as a communications interface, mediating between endpoint instances (that is, publishers and subscribers in application processes) and the bus.

Inside a Transport

The following diagram presents a generalized view of transports and their operating roles.

Transports and Bus

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 type and details of the bus remain hidden from application code.
  • The bus is conceptually outside the application processes. Transports 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.