Clarification on cancelling a block-wise request in the middle of transaction at client's end about libcoap

[mrdeep1]

It would be helpful to know which way the large file is getting transferred. Also, whether you are using the Block (RFC7959) or Q-Block (RFC9177) methods. The CoAP protocol has different timeouts (RFC7252 and RFC9177), some of which are configurable by libcoap (furthermore some of the derived timeouts have configurable sub-component timeouts).

[fun-works]

We are using coap_add_data_large_request() to provide the large chunk of data available in heap. We are using Block transfer and not Q-BLock.

[mrdeep1]

So, assuming that you are using CON over DTLS/UDP, then for the transmission of an individual block, it will timeout after MAX_TRANSMIT_WAIT which defaults to 93 seconds if that block is not acknowledged by the server (lossy network / server crashes etc.). MAX_TRANSMIT_WAIT can be changed by modifying ACK_TIMEOUT and MAX_RETRANSMIT (don't change ACK_RANDOM_FACTOR) - see coap_recovery(3).

For this, the NACK handler is called with COAP_NACK_TOO_MANY_RETRIES after MAX_TRANSMIT_WAIT .

From the coap-server's perspective, if it does not receive all of the blocks of the file after an idle time (no packets seen) of _MAX_TRANSMIT_WAIT before the giving up on receiving all the blocks of the overall payload.