Most developers already know that the Set Database Parameter(Idle connections timeout) should be less than the timeout of any routing device that sits between their 4D Server and 4D Client machines; however it is important to note that this same guideline should also be followed for Set Database Parameter(4D Remote Mode Timeout) and Set Database Parameter(4D Server Timeout).

This is because the value expressed for Set Database Parameter(4D Remote Mode Timeout) and Set Database Parameter(4D Server Timeout) is also used for the interval at which a packet is sent from the server to the connected clients (and from the client to the server).

In the situation where a routing device is actively closing inactive TCP sockets, this packet also acts as a keep-alive keeping port 19813 open; in which case the value should be less than the routing device attempting to close the connections. The insert below contains the test results showing this behavior and the explanation of why it occurs:

Following is a screenshot of a possible error encountered when the 4D Remote Mode Timeout and 4D Server Timeout was set to a value HIGHER than the timeout on the router/firewall/wap/etc. The error above was encountered after leaving an output form open and waiting an extended period of time, 10 minutes in this situation, and then double-clicking on a record after the 10 minutes had passed. In our test environment, a Netgear WNR3500L router with the v24 sp2 (SVN Revision 14826M NEWD-2 K2.6 Eko) of DD-WRT was used with the TCP timeout set to 180 seconds (3 minutes). The Idle connections timeout was set to 30 seconds (using both positive and negative values, thus 2 calls, in both on startup and on server startup), however the 4D Remote Mode Timeout and 4D Server Timeout was set to 4 minutes. In this test environment, the 4D Remote Mode Timeout and 4D Server Timeout being set to 4 minutes, which was higher than the 3 minute timeout on the router, caused the keep-a-live packets to never be sent, thus the router closed the connection as depicted in the following diagram:

In fact, it is the standard behavior.

Here is an overview of how it works:

• You can set the network timeout in the preferences dialog or via Set Database Parameter. The value is stored in the 4D preferences.xml file.
  
  • That means the settings is common to all databases running on the same machine.
    
  • That also means that the server and each client may have different settings...
  
  
• If the timeout has never been set on one machine, the value is 2 minutes.
  
• Each timeout period (by default 2 minutes), the server and each of the clients send a packet to the other side and await for it to respond. If the other side has not responded within the timeout period, the connection is closed.
  
  • While exchanging the timeout packet, each side updates its connection timeout value to the minimum of the two timeout values of both sides. Say the server has timeout 10 minutes and a client connects with a timeout of 2 minutes, then the server will update its timeout to use 2 minutes.

The important thing to understand is the value given for the time out (4D Remote Mode Timeout and 4D Server Timeout) is also the interval of the request that will be sent by the client to know if there is still a connection.

So if the 4D Remote Mode Timeout and 4D Server Timeout is less than the router time out, no problem is encountered because a request hello will be sent and will generate a traffic thus resetting the inactivity for the TCP socket.

If the 4D Remote Mode Timeout and 4D Server Timeout is higher than the router time out, no hello request will be sent and the TCP socket connection will be most likely be closed by the router.