timeout=seconds

• TCPIP, TLS, HTTP, HTTPS

240 seconds

If any connect, read, or write attempt fails to complete within the specified time, the client fails the synchronization.

Throughout the synchronization, the client sends liveness updates within the specified interval to let the MobiLink server know that it is still alive, and MobiLink sends back liveness updates to let the client know that it is still alive. To prevent slow networks from delaying the timeout past the specified time, MobiLink clients send keep-alive bytes to the MobiLink server at an interval of half the timeout value. When this value is set to 240 seconds, the keep-alive message is sent every 120 seconds.

You should be careful about setting the timeout to too low a value. Liveness checking increases network traffic because the MobiLink server and the client must communicate within each timeout period to ensure that the connection is still active. If the network or server load is very heavy and the timeout period is very short, a live connection could be abandoned because the MobiLink server and dbmlsync were unable to confirm that the connection is still active. The liveness timeout should generally not be less than 30 seconds.

The maximum timeout is 10 minutes. You can specify a larger number than 600 seconds, but it is interpreted as 600 seconds.

The value 0 means that the timeout is 10 minutes.

For information about how to set network protocol options with dbmlsync, see CommunicationAddress (adr) extended option.

For information about how to set network protocol options with UltraLite, see Network protocol options for UltraLite synchronization streams.

The following example sets the timeout to 300 seconds.

On a SQL Anywhere client, the implementation is:

dbmlsync -e "adr=timeout=300"

In an UltraLite application written in embedded SQL or C++, the implementation is:

synch_info.stream_parms = TEXT("timeout=300");