Client: secure channel shall not be closed on request timeout hint expiration
Description
The OPC UA specification part 4 indicates that the TimeoutHint request header parameter shall be used by the client to set a timeout on a per-call basis. But it also indicate that the server might ignore it on synchronous services and in any case shall not send a Bad_Timeout status service back before the effective TimeoutHint expiration.
As a consequence the client will not receive the message before the TimeoutHint expiration. Since this expiration is used to consider a timeout on request and the stack automatically close the connection in this case, implementation seems incorrect.
Analysis
The server has no timeout limit defined to send the response since the timeout is an hint and the specification makes only mandatory to send a Bad_Timeout service response in case of an expired PublishRequest (using timeoutHint). It seems to indicate that the client shall not close the connection in case of reception of the service response after the timeoutHint expiration. But it might report the timeout expiration to the application to avoid it waiting longer and might ignore the response received later.
Implementation
Configuration of timer expiration on request timeoutHint
: since the server might be late without sending a Bad_Timeout service result in several cases, this expiration should be delayed to accept a reasonable delayed response. This timer will then be defined to expire at 2*timeoutHint
.
On request timeout timer expiration: the secure channel shall not be closed but the the request timeout event shall be triggered to the services layer. The context on the request shall be kept to know the requestId is still valid if response received later (avoid connection closure on bad requestId), context state shall be modified to indicate to ignore response when received (only log traces since service layer had a timeout event).