Fix packet recovery support for BLOCK1 option in examples for lossy connections #271
Conversation
mrdeep1
changed the title
|
Updated client code to ignore duplicate BLOCK1 ACKs |
…onnections examples/client.c examples/coap-server.c For the client, the next block to transmit is always now the last acknowledged block plus one. If the client receives a duplicate BLOCK1 ACK, the duplicate ACK is ignored by checking the message ids. For the server, it no longer rejectes a duplicate BLOCK1 request, but does still object if there is a gap in the provided data due to a missing block. In otherwords, the blocks must arrive sequentially from the client.
|
duplicate text corrected. |
There was a problem hiding this comment.
You cannot use the ACKs (i.e., the tid) to trigger transmission of new blocks. The ACK is visible only on the CoAP message layer and its only significance is for stopping retransmission of confirmable messages. Blockwise transfer is a lock-step protocol hence you need to wait for a 2xx response to the last request to trigger transmission of the next block. The response-to-request mapping must be done through the token (as only one outstanding block is allowed, there is no issue when using the same token for subsequent blocks).
|
@obgm Your comment is an useful overview of what should and should not be taking place during blockwise transfers. It is more a case of my explanation in the commit message that may be causing the confusion here, by using ACK to refer to the 2.31 response acknowledge of the block1 that has recently been sent to the server, not tid. The underlying issue here was the (first) CON PUT request not getting responded to within the coap retransmit timeout (as the server was busy doing other things) and so the server had a queue of the same PUT block requests - which it then responded (correctly) to one by one with the appropriate 2.31 response once it was able to process the PUT requests. The coap-client was seeing these 2.31 and sending off the next block after bumping the current sent block counter - so, if block 0 was sent say 3 times due to the CON layer timeouts, server responded acknowledging block 0 3 times by which time the client has sent block 3 but should have only being sending block 1). The num= part of the patch fixes this, so that only the next block number (X + 1) is sent following the 2.31 acknowledgement response for block X. The secondary issue was that the coap-client then was sending block 1 3 times on receipt of the 3 2.31 server responses for block 0. I could not find clarity in the RFCs as to what the correct behavior is for this, but believe that as the server has acknowledged safe delivery of block X, there is no need to re-transmit it. Here, I do use the message id (tid) to check if there is a duplicate response (tid will not change when the CON is re-transmitted due to a timeout) and do not re-transmit the same block X that has been acknowledged. An alternative to this would be to remember the last block acknowledged by a 2.31 or 2.01 or 2.04. |
|
Got it, thanks for clarifying. Changes look good to me and will be merged. |
examples/client.c
examples/coap-server.c
For the client, the next block to transmit is always now the last acknowledged (by 2.31 response)
block plus one (unless of course if there is a block size change which adjusts the block numbers).
If the client receives a duplicate BLOCK1 2.31 (or 2.01 or 2.04) acknowledge response, the duplicate 2.31 acknowledge response is ignored by checking the message ids. The duplication may happen if the server server is slow to respond to a CON request, and the client re-transmits the CON request after a timeout.
For the server, it no longer rejects a duplicate BLOCK1 request, but does
still object if there is a gap in the provided data due to a missing block.
In other words, the blocks must arrive sequentially from the client.