Persistence Server Transports

Each persistence server uses special-purpose transports of two kinds: cluster transports and client transports.

Cluster transports communicate between a server and other servers in the cluster.
Client transports communicate between a server and its client processes.

Administrators must configure the details of these transports as part of the persistence server definition (rather than as separate transport definitions).

To configure these transports, see Persistence Server Definition Reference.

Alternate Client Transport

Consider a heterogeneous environment in which the client host computers have different transport capabilities. For example, some hosts support RDMA transports, while others do not. For best performance, each client would use the fastest available transport protocol.

In such situations you can define a second client transport, called the alternate client transport, and assign clients on specific hosts to use that alternate transport. All other clients use the regular client transport.

To configure this transport, see Persistence Server Definition Reference.

Client Transport and Non-Blocking Send

Administrators can choose whether the client transport uses blocking or non-blocking send. This setting affects only the client end of the transport, as the server end always uses non-blocking send.

This choice is relevant only when the publisher mode is Store - Send - No Confirm, because otherwise the application publishing rate is limited by confirmations from the persistence server. (See Publisher Mode.)

Furthermore, this choice has an effect on behavior only during peak message bursts, that is, if application publishing overwhelms the quorum leader:

To favor maximum application publishing speed while accepting potential message loss in the store, choose non-blocking send.
To favor minimum message loss in the store while throttling application publishing speed, choose blocking send.