coap_client: timespan keeping internal_requests

[boaks]

A internal_request is currently reused, when

1. the request is not longer ongoing
2. and the exchange_lifetime_exceeded

(see coap_client.c - get_free_request )

The second will the cause, that each internal_request (CON) will not be reused for about (internal_req->pending.params.ack_timeout * COAP_EXCHANGE_LIFETIME_FACTOR).

While that may make sense for a separate CON response, I don't see, why that is required for a piggybacked response.
With this extra time it requires either a larger value for CONFIG_COAP_CLIENT_MAX_REQUESTS (and so more RAM), or throttles sending messages (see Nordic DevZone - COAP_CLIENT_LIB request issue ).

Are there any considerations, why internal request should be kept for this additional time?
Even if the response is a piggybacked ACK?

[rlubos]

I can only think of internal implementation reasons, the CoAP client thread is only active (i.e. actively polling the socket) when there are active exchanges:

zephyr/subsys/net/lib/coap/coap_client.c

Lines 1091 to 1096 in 732a3a5

	if (has_ongoing_exchanges()) {
	continue;
	} else {
	idle:
	k_sem_take(&coap_client_recv_sem, K_FOREVER);
	}

Therefore, in case the request context was released right after receiving piggybacked response, any duplicate replies (for example in case the request was retransmitted in a slow network, but not actually lost) would be sitting on the socket until the next request is sent. Whether or not that's a big issue, I'm not sure, shouldn't matter in case of higher traffic.

CC @SeppoTakalo for visibility.

[rlubos]

Uhm, so much going on in different fields, I totally forgot about this one: #86293
@boaks So it seems this very case was addressed by Seppo a few months ago (it is in NCS now, but wasn't there yet for v3.0.0).

[boaks]

Thanks a lot! That will improve it.
In the meantime the user may use a larger value CONFIG_COAP_CLIENT_MAX_REQUESTS in combination with retries of the request after a short pause.