New ServerNet Network Layer

Originally introduced in 4D v14 R5

4D v15 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.

Implementation note: The ServerNet network layer is provided in "preview" release in 4D v15.

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

New options allow you to activate/deactivate the ServerNet.

A new compatibility option allows you to activate or deactivate the legacy network layer in your 4D Server at any time. You can use either:

• the Use legacy network layer option in the Database Settings dialog box (see below), or
• the Use legacy network layer constant in SET DATABASE PARAMETER (this point is covered in the Get database parameter and SET DATABASE PARAMETER section)

The new compatibility option is located on the Compatibility page:

Note: This option is ignored in 4D Server 64-bit versions for OS X; only ServerNet can be used on this platform.

By default, this option is:

• unchecked for new databases created with 4D v15 (or 4D v14 R5) and later versions (they use the new ServerNet layer),
• checked for existing databases that are converted (they use the legacy network layer).

You can check or uncheck the option as necessary, for example, during the migration phase of your client applications (see below).

Note that in case of a modification, you need to restart the application for the change to be taken into account. Any client applications that were logged must also be restarted to be able to connect with the new layer (the minimum client version for using the ServerNet layer is 4D v14 R4, see below).

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

• Clients in version 4D v15 and higher (or 4D v14 R4 and higher) can connect with no modification. 
• Clients in previous versions (v14.x and all other v14 'R' releases) must first be upgraded in order to be able to connect to the server.

If your application works with merged 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 with the "Use legacy network layer" network parameter activated.
   This configuration allows all clients to connect.
   Note: Keep in mind that the 4D Server v15 64-bit version 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 activate the "Diagnostic log recording" file. When it 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 the client manually.