# 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
>     					};