Network Configuration for SQLstream s-Server

<< Click to Display Table of Contents >>

Navigation:  Administering SQLstream Blaze > Configuring s-Server >

Network Configuration for SQLstream s-Server

Previous pageReturn to chapter overviewNext page

A SQLstream system currently makes one type of network connections:

Clients receiving data by means of SDP, on default port 5570. (SDP is SQLstream's own streaming data protocol.)

SDP connections use TCP transport and require a valid route from the client driver to the server. However, a server can be configured to use a different port, as described below.

Note that the jdbc connection string refers to the SQLstream s-Server using a particular SDP port: jdbc:sqlstream:sdp://host:port. The suffix port is optional, since the SQLstream client driver automatically supplies "5570" as the default SDP port value. However, if the server is actually using a different SDP port, its number must appear explicitly in the connect string.

Configuration Properties

Both types of connections, for requesting or receiving data, can be configured by setting the properties listed in the table below.

Configuration properties can be found (in $SQLSTREAM_HOME/s-Server/support) in either aspen.config or in the main properties file, aspen.properties. However, those files are not to be edited directly: the properties can be overridden by editing aspen.custom.properties, including the SDP port property aspen.sdp.port.

Configuration Element

Configuration Parameter

Port on which the server listens for SDP connections from the driver

aspen.sdp.port

Default: 5570

Maximum transmission unit (MTU) for SDP connections.

It is the maximum size of a TCP packet in a SDP connection.

aspen.sdp.mtu

Default: 65536

Number of milliseconds between sending SDP EchoRequest frames.

Echo frames are pings inside of an SDP connection.

aspen.sdp.pingTimerMs

Default: 2000

Minimum number of milliseconds of idle time on a given link before timing out the link on the assumption that the connection is broken or that the peer has crashed

aspen.sdp.linkTimeoutMs

Default: 10000.

Throw exception: If true and link becomes mis-synchronized, exception is thrown. Exists for debugging; for production, should be set to false.

aspen.sdp.throwOnProtocolError

Default: false.

Maximum size of a block of row data sent from the driver to the server. If multiple rows can fit inside of a buffer of size blocksize, then they will be packed into one TCP packet. MTU doesn't effect how many tuples are in a TCP packet, it only limits the maximum size of a TCP packet.

aspen.sdp.blocksize

Default: 65536, the maximum.

Minimum value is 512.

Number of independent blocks a driver can receive. Generally the number of statements running on a specific driver. This is rarely used.

aspen.sdp.rxblocksize

Default: 4. Minimum value is 2.

Maximum value is maximum value of Java Integer class.

Multiple NIC cards

SQLStream generally binds its server to the "ANY" TCP IP address (0.0.0.0) which allows it to listen for network connections from any IP for which the host is receiving traffic. Generally this is only one public IP address and one loopback IP address (usually 127.0.0.1).

On some more complex production server environments, machines can have multiple NIC cards which might handle traffic on different IP addresses and/or networks. In these environments, SQLStream can be configured to listen for network connections upon one and only one IP address if desired. The default is still to bind to all IPs.

To bind to a single IP, you must enter the desired IPv4 address in the aspen.custom.properties file as both the aspen.controlnode.sdp.host property and aspen.controlnode.url property. In the case of the aspen.controlnode.url property, enter the value in the following format sdp://<IPv4 address>:<port>. The port may be omitted and in this case you should remove the trailing : as well.

Some common network-related problems

Firewalls. Make sure that the SDP ports used by SQLstream are open and that valid routes between the driver and server exist.

NATs. Drivers can be behind NATs but if the server is behind a NAT it will require port forwarding unless both the driver and server are behind the same NAT. This is because a driver must be able to open connections on the server.