For blockwise transfers, _findRequestBlockStatus is called, which in turn calls _prepareBlockCleanup. Once blockwise requests complete, I take it the scheduled block cleanup has to be terminated by calling _clearBlockCleanup? This prevents false-positive timeouts on successfully completed block requests and responses.
Verified that the problem exists for both block1 requests and block2 responses, and that this PR fixes those issues. The reason it doesn't show in the examples is because they are terminated before the timeout. Hope my fixes made their way to the right place, new to this code base :)
A nitpick which this PR doesn't address is that block1 timeouts provoked in this way are reported as block2 timeouts. Since the timeouts themselves are a bug, it could just be an artifact of that... Or all block1 timeouts are actually reported as block2. Notably the token is null and a message with this id is never sent to the server/logging proxy. Example:
2022-03-29 03:30:04.144: WARNING: >> Block2 transfer timed out:
<<< Request Message >>>
Type: 0, Code: POST, Id: 14379, Token: null,
Options =
[
If-Match :
Uri Host : None
E-tags :
None
Uri Port : 10500
Location Paths:
Uri Paths : large-create
Content-Type : 0
Max Age : None
Uri Queries : Uri-Query: title=This is an SJH Put request
Accept : 0
Location Queries :
Proxy Uri : None
Proxy Scheme : None
Block 1 : None
Block 2 : None
Observe : -1
Size 1 : 0
Size 2 : 0
],
Payload :
Big text here...
... as opposed to the block2 timeouts I'm provoking (where the token exists, and the message has actually been sent):
2022-03-29 04:01:21.152: WARNING: >> Block2 transfer timed out:
<<< Request Message >>>
Type: 0, Code: GET, Id: 24471, Token: 00001c98,
Options =
[
If-Match :
Uri Host : Uri-Host: coap.me
E-tags :
None
Uri Port : 5683
Location Paths:
Uri Paths : large
Content-Type : None
Max Age : None
Uri Queries :
Accept : None
Location Queries :
Proxy Uri : None
Proxy Scheme : None
Block 1 : None
Block 2 : None
Observe : -1
Size 1 : 0
Size 2 : 0
],
Payload :
null
For blockwise transfers,
_findRequestBlockStatusis called, which in turn calls_prepareBlockCleanup. Once blockwise requests complete, I take it the scheduled block cleanup has to be terminated by calling_clearBlockCleanup? This prevents false-positive timeouts on successfully completed block requests and responses.Verified that the problem exists for both block1 requests and block2 responses, and that this PR fixes those issues. The reason it doesn't show in the examples is because they are terminated before the timeout. Hope my fixes made their way to the right place, new to this code base :)
A nitpick which this PR doesn't address is that block1 timeouts provoked in this way are reported as block2 timeouts. Since the timeouts themselves are a bug, it could just be an artifact of that... Or all block1 timeouts are actually reported as block2. Notably the token is null and a message with this id is never sent to the server/logging proxy. Example:
... as opposed to the block2 timeouts I'm provoking (where the token exists, and the message has actually been sent):