The API option name suggests that SRTO_CONNTIMEO represents the actual connection timeout, but in Rendezvous mode the configured value is treated as an internal parameter from which the effective timeout is derived.
As a result:
- Applications cannot specify the desired timeout directly.
- The same configuration value produces different behavior depending on connection mode.
- Users must know about the hidden 10x multiplier and divide their intended timeout by 10 when using Rendezvous.
The current behavior is documented but arguably violates the principle of least surprise.
According to the documentation:
This is the time up to which the connecting facility will attempt to connect and wait for the response from the remote endpoint before giving up with error status. The value applies for both caller and rendezvous modes. For the rendezvous mode (see SRTO_RENDEZVOUS) the effective connection timeout will be 10 times the value set with SRTO_CONNTIMEO.
This behavior is unintuitive from an API user's perspective.
When an application configures 3000 ms, the expectation is typically that the connection attempt will fail after approximately 3 seconds, regardless of the connection mode. nstead, in Rendezvous mode the actual timeout becomes 10 times more, i.e. 30000 ms or 30 seconds.
This introduces an implicit scaling factor that users must discover in the documentation and manually compensate for.
Suggested Improvement
Consider interpreting SRTO_CONNTIMEO as the effective timeout in all connection modes.
Make a note in the documentation to use a higher value for rendezvous connections.
Maybe report some info or warning level message regarding potentially too low connection timeout configured.
The API option name suggests that
SRTO_CONNTIMEOrepresents the actual connection timeout, but in Rendezvous mode the configured value is treated as an internal parameter from which the effective timeout is derived.As a result:
The current behavior is documented but arguably violates the principle of least surprise.
According to the documentation:
This behavior is unintuitive from an API user's perspective.
When an application configures 3000 ms, the expectation is typically that the connection attempt will fail after approximately 3 seconds, regardless of the connection mode. nstead, in Rendezvous mode the actual timeout becomes 10 times more, i.e. 30000 ms or 30 seconds.
This introduces an implicit scaling factor that users must discover in the documentation and manually compensate for.
Suggested Improvement
Consider interpreting
SRTO_CONNTIMEOas the effective timeout in all connection modes.Make a note in the documentation to use a higher value for rendezvous connections.
Maybe report some info or warning level message regarding potentially too low connection timeout configured.