Interface Timeouts - nthallen/monarch GitHub Wiki

The purpose of Interface Timeouts are to establish limits on how long the Interface will spend attempting a particular I/O operation on its associated I/O channel. A timeout on a read or write operation may indicate that the associated resource is busy or failing. A timeout on a Socket's connect() may occur if the remote resource is unavailable.

In some of these cases, the response to the timeout is automatic and requires little or no customized configuration. If a Socket's connect() times out, by default, it will retry the connection indefinitely.

There are cases where a specific application may need a timeout that is not directly tied to the associate I/O resource or where the desired action is not already configured action. This is where I would like to document how it make sense to handle these situations with examples from code I am working on.

June 7, 2021: I am trying to speed up connection to a remote socket that may be unavailable when I first try to connect. Ordinarily the connect() operation times out in the network driver after about 90 seconds if response to the initial handshake is not received. What that means in practice is if that resource comes on line a few seconds after the initial packet is sent, we have to wait, say 90 seconds before retrying, even though the resource may be ready in 5 seconds. I want to set a timeout on the connect() operation. As implemented today, connect() will recognize the timeout and attempt to reconnect, just as it would if the timeout came from the network driver. The problem is that since the reconnect happens automatically, I do not have an opportunity to set another timeout on those subsequent connect()s.

Here, a timeout during connect() has a predefined action: reconnection with an adjustable time delay. I can disable the predefined action by configuring the Socket not to retry, and then implement my preferred action in connect_failed(). Fair enough, but the action I need to take in this case may involve delaying a bit before retrying. Specifically, if connect() fails immediately, and connect_failed() calls connect() immediately, we get and endless recursion and a stack overflow.

On the other hand, a timeout when the Socket is disconnected is also predefined as triggering a delayed reconnect (as by connect_later()). That means I cannot use a timeout I set while disconnected to do my own connect() with timeout. Note that with an Interface, it is possible to set a timeout even if the fd has not been initialized (fd == -1). It seems to me that a Socket should have the same option.

It is clear here that I will have to make a change to Socket to give me the flexibility I need. Which change should I make?

  • Add a feature to connect() to configure a timeout which will be applied on every connect()?
  • Add support for a timeout while disconnected to call process_timeout() if the Socket is not configured for retries? Por qué no los dos? The latter would be sufficient to implement the functionality I seek, but would still require some care in constructing the solution. The former would be a lot more convenient, and I suspect this particular functionality may be quite useful. However, the latter would leave open the option of implementing some other as yet unidentified functionality.