search

obgm / libcoap

A CoAP (RFC 7252) implementation in C
Other
790 stars 422 forks source link

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

Open fun-works opened 3 months ago

fun-works commented 3 months ago

Environment

libcoap Configuration Summary

Libcoap version 4.3.4

Problem Description

I am transferring a large file using blockwise transfer. I want to have an option to provide a max time-out value upon which the transfer would stop if it is not completed. Is there an option in libcoap to do that ?

mrdeep1 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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.

mrdeep1 commented 2 months ago

@fun-works Do you need any more help on this, or can this now be clossed?