Network and Client-Server options

You can set various parameters concerning the network and the client-server communication on different tabs of the Client-Server page in the Database settings (accessible on both 4D in remote mode and 4D Server):

Moreover, beginning with 4D Server v14 R5, a compatibility option allows you to enable or disable the former network layer at any time:

These parameters are detailed in this section.

This option lets you indicate whether or not the 4D Server database will appear in the list of published databases.

• When this option is checked (default), the database is made public and appears in the list of published databases (Available tab).
• When the option is not checked, the database is not made public and it does not appear in the list of published databases. To connect, users must manually enter the address of the database on the Custom tab of the connection dialog box.

Note: If you modify this parameter, you must restart the server database in order for it to be taken into account.

This option lets you change the publication name of a 4D Server database, i.e., the name displayed on the dynamic Available tab of the connection dialog box (see the Connecting to a 4D Server Database section). By default, 4D Server uses the name of the database structure file. You can enter any custom name you want.

Note: This parameter is not taken into account in custom client-server applications. In theory, the client application connects directly to the server application, without passing by the connection dialog box. However, in the event of an error, this dialog box will appear; in this case, the publication name of the server application is the name of the compiled database.

This option lets you change the TCP port number on which 4D Server publishes the database. This information is stored in the structure of the database and on each client machine. By default, the TCP port number used by 4D Server and 4D in remote mode is 19813. Customizing this value is necessary when you want to use several 4D applications on the same machine with the TCP protocol; in this case, you must specify a different port number for each application. When you modify this value from 4D Server or 4D, it is automatically passed on to all the 4D machines connected to the database. To update any other client machines that are not connected, you just need to enter the new port number (preceded by a colon) after the address of the server machine on the Custom page of the connection dialog box at the time of the next connection. For example, if the new port number is 19888:

Note: When a 4D Server uses IPv4, only databases published on port 19813 are visible on the Available dynamic publication tab.

4D Server uses several TCP ports for communications between internal servers and clients:

• SQL Server: 19812 by default (can be modified via the "SQL" page of the Database Settings).
• Application Server: 19813 by default (can be modified via the "Client-Server/Publishing" page of the Database Settings, see above).
• DB4D Server (database server): 19814 by default. This port number cannot be modified directly but it always consists of the application server port number + 1.
  When a 4D client connects to 4D Server, it uses the TCP port of the application server (19813 or the port indicated after the colon ':' in the IP address shown in the connection dialog box). Connection to other servers via their respective ports is then automatic; it is no longer necessary to specify them.
  Note that in the case of access via a router or a firewall, the three TCP ports must be opened explicitly.

This option allows you to implement SSO (Single Sign On) capabilities in your 4D Server database on Windows. When you check this option, 4D transparently connects to the Active directory of the Windows domain server and gets the available authentication tokens.

This option is described in the Single Sign On (SSO) on Windows section.

When Single Sign On (SSO) is enabled (see above), you must fill in this field if you want to use Kerberos as your authentication protocol.

This option is described in the Single Sign On (SSO) on Windows section.

This device is used to set the timeout (period of inactivity beyond which the connection is closed) between 4D Server and the client machines connecting to it.The Unlimited option removes the timeout. When this option is selected, client activity control is eliminated.

When a timeout is selected, the server will close the connection of a client if it does not receive any requests from the latter during the specified time limit.

When this option is checked, all the 4D remote machines connecting to the database can execute methods remotely. This mechanism is detailed in the section Stored procedures on client machines.

This option lets you activate the secured mode for communications between the server machine and the 4D remote machines. This option is detailed in the Encrypting Client/Server Connections section.

This setting can be used to globally set the updating mode for the local instance of the Resources folder on the connected 4D machines when the Resources folder of the database is modified during the session (the Resources folder is automatically synchronized on the remote machine each time a session is opened). Three settings are available:

• Never: The local Resources folder is not updated during the session. The notification sent by the server is ignored. The local Resources folder may be updated manually using the Update Local Resources command.
• Always: The synchronization of the local Resources folder is automatically carried out during the session whenever notification is sent by the server.
• Ask: When the notification is sent by the server, a dialog box is displayed on the client machines, indicating the modification. The user can then accept or refuse the synchronization of the local Resources folder.
  The Resources folder centralizes the custom files required for the database interface (translation files, pictures, etc.). Automatic or manual mechanisms can be used to notify each client when the contents of this folder have been modified. For more information, please refer to the Managing the Resources folder section.

This option sets the opening mode for the database structure on client machines. By default, the Read/Write mode is set but you can also set it to Read only in order to prevent the structure from being modified.

This table allows you to set access control rules for the database depending on 4D remote machine IP addresses. This option allows reinforcing security, for example, for strategic applications.

Note: This configuration table does not control Web connections.

The behavior of the configuration table is as follows:

• The “Allow-Deny” column allows selecting the type of rule to apply (Allow or Deny) using a pop-up menu. To add a rule, click on the Add button. A new row appears in the table. The Delete button lets you remove the current row.
• The “IP Address” column allows setting the IP address(es) concerned by the rule. To specify an address, click in the column and enter the address in the following form: 123.45.67.89 (IPv4 format) or 2001:0DB8:0000:85A3:0000:0000:AC1F:8001 (IPv6 format).
  You can use an * (asterisk) character to specify “starts with” type addresses. For example, 192.168.* indicates all addresses starting with 192.168.
• The application of rules is based on the display order of the table. If two rules are contradictory, priority is given to the rule located highest in the table.
  You can re-order rows by modifying the current sort (click the header of the column to alternate the direction of the sort). You can also move rows using drag and drop.
• For security reasons, only addresses that actually match a rule will be allowed to connect.
  In other words, if the table only contains one or more Deny rules, all addresses will be refused because none will match at least one rule. If you want to deny only certain addresses (and allow others), add an Allow * rule at the end of the table. For example:
  - Deny 192.168.* (deny all addresses beginning with 192.168)
  - Allow * (but allow all other addresses)
  By default, no connection restrictions are applied by 4D Server: the first row of the table contains the Allow label and the * (all addresses) character.

Starting with 4D v14 R5, 4D applications contain a new network layer, named ServerNet, to handle communications between 4D Server and remote 4D machines (clients). ServerNet is based on a modern and robust API. It is easy to maintain and will facilitate the implementation of the latest network technologies while providing a high level of performance.

Using ServerNet is transparent from the user's point of view. Keep in mind, however, that when ServerNetis used, the names of databases published in secured mode are no longer preceded by a "^" character as was the case with the former network layer (see Encrypting Client/Server Connections).

The former "legacy" network layer is still supported in order to ensure compatibility for existing databases. ServerNet is automatically used in newly created databases.

There are options that allow you to enable/disable the ServerNet. To ensure that your applications will benefit from future network evolutions, we recommend that you enable ServerNet gradually in all your databases.

You can enable or disable the legacy network layer in your 4D Server at any time. You can use either:

• the Use legacy network layer constant with the SET DATABASE PARAMETER command, or
• the Use legacy network layer option in the Database Settings dialog box (see Compatibility page):
  

Note: As indicated in its title, this option is ignored in the 64-bit version of 4D Server for OS X; only ServerNet can be used on this platform. 

By default, the serverNet network layer is:

• automatically enabled in new databases, created with 4D v14 R5 or subsequent versions,
• automatically disabled in converted databases.

When you activate the ServerNet layer in your existing server application, only compliant 4D client applications will be able to connect:

• Client applications in version 15 (starting with 4D v14 R4) can connect with no modification. 
• Client applications in previous versions (v14.x and all previous v14 'R' releases) must first be upgraded in order to be able to connect to the server.

If your application works with merged 4D Volume Desktop clients in versions earlier than v14 R4, and you want to use the 4D Server automatic mechanism to distribute your updated client applications over the network, you need to establish a migration strategy. This strategy must be based upon the following principles:

• Non-compatible clients can only connect to a 4D Server that uses the legacy network layer.
• Updated clients can adapt their protocol dynamically so they can connect to 4D Server v15 and higher, regardless of the network layer that the server is using.

Your migration strategy should follow these steps:

1. Build updated client applications with 4D v15 or higher.
2. Run 4D Server v15 or higher with the "Use legacy network layer" parameter enabled.
   This configuration allows all clients to connect.
   Note: Keep in mind that the 64-bit version of 4D Server for OS X does not support this option. 
3. Wait for a given period of time until every client has connected and downloaded the new version.
   This may last for a day, a week or even longer. During this transition period, both previous and updated clients are able to connect to the legacy network server.
4. Once all the clients have been updated, you can deactivate the legacy network layer and finally switch to the ServerNet on 4D Server.

This strategy is depicted in the following diagram:

During the migration process, we recommend that you enable the "Diagnostic log recording" file. When this file is activated, 4D Server logs each client update request in this file, allowing you to monitor the process. This log is not activated by default: you need to call the SET DATABASE PARAMETER command with the Diagnostic log recording constant set to 1.

For each update request, the following information is logged:

• client IP
• client version
• "Update client" event

Monitoring the log file is also useful after you have switched the server to the ServerNet network layer, to make sure all the clients have been updated properly. If a non-compatible client attempts to connect, the server logs the following entry:

• client IP
• client version
• "Fail to connect" event

In this case, you can decide, for example, to update client manually.