obgm/libcoap

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

fun-works opened this issue · 4 comments

fun-works commented

Environment

  • Build System: [CMake]
  • Operating System: [Linux]
  • Operating System Version: [ ]
  • Hosted Environment: [None]

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

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

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

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

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