coap_net.c: Fix CSM timeouts in coap_client_delay_first()

[mrdeep1]

Reduce timeout to 1 second and enter established state for servers that only partially implement RFC8323 for TCP support, but do not send a CSM.

[JimmyBaize]

I tested it and it works as expected.

But I have a question. why not use csm_timeout (from coap_context_set_csm_timeout) as CSM timeout .

[JimmyBaize]

Is it possible to use csm_timeout (from coap_context_set_csm_timeout) ?

[mrdeep1]

Interesting question. csm_timout is in seconds and by default has a value of 30 seconds. The logic that uses this timeout closes the TCP connection if this timeout occurs and was introduced in 2018.

While it is unlikely that anyone actually calls coap_context_set_csm_timeout(), it is possible and we have to maintain binary functionality with new code, so cannot make use of csm_timeout here.

[mrdeep1]

That said, the connection can never get closed now on a CSM timeout from the CoAP Server even if a low value of 1 to coap_context_set_csm_timeout() will more likely trigger the new CSM is not coming, continue anyway logic, rather than disconnect the session.

I am reluctant to change the parameter of coap_context_set_csm_timeout() to millisecs, rather than seconds as that definitely breaks backward/forward binary compatibility. But a coap_context_set_csm_timeout2() could be created.

As a note here, there must be sufficient delay before timeout so that a CSM response from a slow startup server can be processed before building (in particular the call to coap_session_max_pdu_size()) / sending out the first request.

I think 1000 millisecs is a reasonable low limit timeout to get a CSM response and would not recommend that it goes much lower.

[JimmyBaize]

Now we allow to keep TCP session when CSM time out. so can we create a coap_context_set_csm_timeout_ms , and use it here?
coap_context_set_csm_timeout_ms and coap_context_set_csm_timeout() to modify the same variable(csm_timeout
in milliseconds)
I want to use a shorter delay to skip waiting for a CSM response, because my existing CoAP cloud service uses Californium (CSM is not supported).

[JimmyBaize]

Suppose we change the csm_timeout variable to milliseconds, and change coap_context_set_csm_timeout() to

void
coap_context_set_csm_timeout(coap_context_t *context,
                             unsigned int csm_timeout) {
  context->csm_timeout_ms = csm_timeout*COAP_TICKS_PER_SECOND;
}

I’m not sure if coap_context_set_csm_timeout_ms and coap_context_set_csm_timeout() can reference the same variable.
If there are two variables, what is the difference between the two timeout variables?

[mrdeep1]

As the current usage of coap_context_set_csm_timeout() logic will never trigger and disconnect the TCP session, all that internal logic can get removed, but coap_context_set_csm_timeout()/coap_context_get_csm_timeout() will still need to be there and coap_context_get_csm_timeout() needs to return an appropriate value.

It appears that Californium have no significant desire to fix the CSM issue, but is used by people such as yourself. I think the way forward here is to tag as deprecated coap_context_set_csm_timeout()/coap_context_get_csm_timeout() and create a new coap_context_set_csm_timeout_ms() (using a different internal variable) as coap_context_set_csm_timeout() does not give you the ability to define something under 1 second (note that COAP_TICKS_PER_SECOND is not always 1000). Defining it as 0 for coap_context_set_csm_timeout() does not tie up with the current documentation

       The coap_context_set_csm_timeout() function sets the number of seconds to wait for a (TCP) CSM negotiation
       response from the peer to csm_timeout for context. 0 (the default) means wait forever.

[JimmyBaize]

OK.The idea of creating a new coap_context_set_csm_timeout_ms() is good.

[mrdeep1]

Code changes pushed with support for coap_context_set_csm_timeout_ms(). The minimum settable value is 10 milliseconds (and the largest 10,000 milliseconds). The timeout starts from when the TCP session connects (or from when TLS is established if appropriate).

A warning is generated if a CSM is received after the CSM timeout logic has timed out, indicating what the minimum timeout should be. When using libcoap.net as a host, the delay in receiving a CSM is of the order of 32 milliseconds.

In your case, as there is no receipt of a CSM signalling Block transfers are supported, the client reports for each block that is transferred (as debug log) Remote end did not indicate CSM support for Block1 enabled, but still sends the block.