PIMS Knowledge-Base Record

Network Connection Timeouts

Author:

DSM

Type:

General

PIMS/4D Network Requirements:

The server architecture that PIMS uses to communicate as Client/Server (4D) requires an uninterrupted network communication.  If a socket opened by 4D is closed by a device in the network, the connection breaks and a restart is required.  This is not a bug, 4D is designed to need a stable network.

The Idle Connection Timeout database parameter places an idle socket connection into a postponed state, this is a graceful closure of the communication socket that is mutually accepted by both the 4D Client and the 4D Server. This feature is exposed via the server's "Settings/Client-Server/Network Options/Client-Server Connections Timeout" parameter and it is intended to help prevent disconnections when a router or other device on the network is configured to close idle socket connections.

Although the Idle Connection Timeout feature has existed since PIMS-SQL, it is important to understand that this feature is not available when Encrypted Client-Server Communication is enabled.  This is something we don't recommend anyway.

Therefore, if using encrypted client-server communication, it is critical that the network be setup so that all involved devices do not close connections on their own, including connections that may be considered as “IDLE”. To do so, either disable IDLE close connection totally or set exceptions for the used IP addresses and port ranges.  To learn how to do so, contact the vendor of the used devices, such as routers and managed switches.

Things to try:

Toggling network layer:
This setting can be found under Database "Settings/Compatibility".  If you are on the new network layer, try switching to the legacy network layer by checking the box. Likewise if you are on the legacy network layer, uncheck the box and see whether disconnects still occur.

Increase/Decrease client server timeout:
Disconnects may occur if a client is temporarily unresponsive longer than the timeout setting.  If so, try increasing the timeout and see whether the client continues to be disconnected.

Modified: 05/12/22 - 9:15 PM