Chapter 5. The bisocket transport

The bisocket transport is derived from the socket transport and differs in one design feature. It was created for JBoss Messaging, where the design criteria were

  1. message payloads are be sent to client side consumers in callbacks,
  2. push callbacks, being faster, are preferred, and
  3. opening ports on the client side is undesirable.

In the socket transport, push callbacks are handled on the client side by a dedicated SocketServerInvoker, which uses a Java server socket; that is, it opens a port. When a connection is needed on the server side to send push callbacks, a socket is created by contacting the server socket on the client side.

The bisocket transport, instead, uses server sockets only on the server side, including (1) the one created by SocketServerInvoker to create connections to handle ordinary invocations, and (2) a secondary server socket. The first use of the secondary server socket is to create a control connection in response to a request from the client side. Subsequently, all connections for sending push callbacks are created by sending a message over the control connection to the client side, asking it to make a connection to the secondary server socket.

If the control connection fails, then no new calback connections can be created, so it is possible to configure the server side BisocketServerInvoker to ping the client side BisocketClientInvoker at fixed intervals. If the BisocketClientInvoker detects a missing ping, it can connect to the secondary server socket and recreate the control connection.

Originally, JBoss Messaging turned off pinging because the default ping period was small enough to cause spurious failures. Currently, the default values are accepted.

The following bisocket configuration parameters are added to those used in the socket transport:

5.1. Server side parameters

pingFrequency - the frequency, in milliseconds, with which the server side sends a ping over the control connection. The default value is 5000 milliseconds.

5.2. Client side parameters

maxControlConnectionRestarts - the maximum number of times the client side will attempt to recreate the control connection following a ping failure. The default value is 10.

maxRetries - the maximum number of times two processes are attempted: (1) the attempt to create a socket, either for the control connection or for a callback connection, and (2) the attempt to get the port of the secondary server socket. The default value is 10.

pingFrequency - the frequency, in milliseconds, with which the server side is expected to send a ping over the control connection. The default value is 5000 milliseconds.

pingWindowFactor - the value which, when multiplied times the pingFrequency, gives the window within which a ping is expected by the client side. The default value is 2. It follows that the default window is 10 seconds.

secondaryBindPort - the port to which the secondary server socket is to be bound. By default, an arbitrary port is selected.

secondaryConnectPort - the port clients are to use to connect to the secondary server socket. By default, the value of secondaryBindPort is used. secondaryConnectPort is useful if the server is behind a translating firewall.