Managing Network Communications with xSQL

As explained in the Network Communications page, eXtremeDB release 7.1.1795 and later allow the IPv6 address protocol for specifying node addresses. The following section describes issues that can be important for developers porting applications that used network communications in prior versions of eXtremeDB. The Security Measures section describes how to enable password-protection or SSL security for network communications.

IPv4 vs. IPv6 issues

The port of an SQL server can be defined as "<host>:<port>" (or just "<port>" as before). In the case of the "<host>:<port>" form, the "<host>" part defines the address of the interface to bind the listening socket to . For example, the following command line could be used to listen for connections from IPv6 clients on the localhost:

 
    ./xsql -size 100m -p [::1]:10000
     

Whereas the next example command line could be used to listen for connections from IPv6 or IPv4 clients (due to the dual stack) from anywhere:

 
    ./xsql -size 100m -p [::]:10000
     

The SQL port specification in xSQL configuration files allows the same capability. For example, the following are valid port specifications:

 
    sql_port : 5000,
    sql_port : "127.0.0.1:5000",
    sql_port : "[::1]:5000",
     

Security Measures

Please refer to the xSQL Security Measures page for details on password-protection and SSL security for remote SQL connections. (Developers using SSL on Mac OSes, please refer to "A note on mcossl for Mac OS X" on page Managing Network Communications in C for important build and usage information.)

Limit incoming connections

A new parameter, maxWaitListLength, has been added to the OpenParameters structure of the SqlServer(const OpenParameters &params) method. The parameter limits the length of the SQL server's list of the incoming network connections from clients. The elements of this list are served only after one of the existing (connected) clients has been disconnected. The limit prevents the scenario when the list is growing uncontrollably large and wasting the server's resource (sockets). The maxWaitListLength default value is defined as db_max_connections / 2, thus the maximum number of connected clients does not exceed (the current number of connection being served ) + (db_max_connections / 2).

  C++: SqlServer::OpenParameters::maxWaitListLength
  .NET Framework : SqlServer.OpenParameters.maxWaitListLength
  JNI: SqlServer.OpenParameters.maxWaitListLength
  Python: SqlServer(max_waitlist_length=...)
  xsql: sql_servers[].max_waitlist_length
				

On the client side, the RemoteEngine.open() and the DistributedSqlEngine.open() methods take an extra parameter RsqlOpenError *errCode = 0 that reports the reason to the client application for the unsuccessful attempt to connect

					enum RsqlOpenError {
					RSQL_OPEN_NO_ERROR = 0,
					RSQL_OPEN_CONNECT_FAILED,
					RSQL_OPEN_SEND_HELLO_ERROR,
					RSQL_OPEN_REJECTED_BY_SERVER,
					RSQL_OPEN_PROTOCOL_ERROR
					};