A routing connection can be established if one router provides a listener and the other a connector. There is no limit in the number of listener and connectors. You can define any number of listeners on different ports and any number of connectors.
A listener listens on a specific port and can be bound to a particular interface on multi homes machines. It defines a socket factory (default PlainSocketFactory) to use for sockets, created from this listener. Further attributes are a password (which is exchanged with challenge/response) and a host access list which is checked against the host name of incoming socket connections. One can also use SSL by specifying the JSSESocketFactory instead of the PlainSocketFactory. See the "Using SSL" documentation. It is also possible to use Http tunneling. See the "Http Tunneling" documentation.
Note: If you use nonblocking I/O (Network NIO Swiftlet), SSL cannot be used since java.nio doesn't support it.
The following snippet defines a listener on port 4100 with the default PlainSocketFactory and another one listening on port 443 with the JSSESocketFactory and a password:
Example:
<listeners>
<listener name="plainsocket" port="4100">
<host-access-list/>
</listener>
<listener name="sslsocket" port="443"
socketfactory-class="com.swiftmq.net.JSSESocketFactory"
password="secret">
<host-access-list/>
</listener>
</listeners>
A connector is responsible to establish a routing connection. It points to a listener on a remote router and must be of the same configuration concerning socket factory and password. A connector can be enabled and disabled. It is enabled by default. A disabled connector is inactive.
If a connection cannot be established by a connector or is lost, it retries in intervals, specified in attribute "retry-time", to connect. The default "retry-time" is 60000 (1 minute). Retry is only performed if the connector is enabled.
The following snippet defines a connector, pointing to a routing listener on host "chb.acme.com" on port 17884. It uses the JSSESocketFactory and password "let_me_in". The "retry-time" is 2 minutes:
Example:
<connectors>
<connector name="acme"
hostname="chb.acme.com"
port="17884"
socketfactory-class="com.swiftmq.net.JSSESocketFactory"
password="let_me_in"
retry-time="120000"/>
</connectors>
The Routing Swiftlet registers a job "Routing Connector" in job group "Routing" at the Scheduler Swiftlet:
This job takes the name of the routing connector as parameter. It enables the connector at job start and disables it at job stop. Therefore, a connector should be configured as being disabled if it should be used in a job:
Example:
<connectors>
<connector name="acme"
enabled="false"
hostname="chb.acme.com"
port="17884"
socketfactory-class="com.swiftmq.net.JSSESocketFactory"
password="let_me_in"
retry-time="120000"/>
</connectors>
The "Routing Connector" should have a specified maximum runtime in its schedule, otherwise it will not be disabled. If the connector will be enabled during job start and the connection cannot be established, the retry behavior will be executed as described in the section above. Retry ends at job stop.
The following example schedules a "Routing Connector" job for the connector named "acme" every business day at 09:00 with a maximum runtime of 8 hours, so the routing connection will be effectively established (if possible) between 09:00 and 17:00:
SwiftMQ manages its own network buffers on both sides of the wire. The length of the data sent to the network is determined by the underlying SMQP protocol handlers. Only complete requests are sent. Before a request is sent, it is written to a network buffer. The receiving side receives the data into a network buffer as well. Theses buffers are adjusted automatically. However, adjustment may take time when transfering large messages, so it might be necessary to configure buffer/extend sizes that meets the requirements more specific.
Network buffers are initially created with their initial size which is 128 KB by default. If the protocol handler detects that the buffer is full before it can flush it, it will extend the buffer and continues writing until the request is finished or the buffer fills up again which then leads to another extend. The default extend size is 64 KB.
The initial buffer size and the extend size can be specified for:
So it's possible to adjust network buffers for both sides by creating the appropriate routing listeners and connectors.