I used the example in order to get an understanding of the blockwise transfer. Of course, I also read the documentation.
I have the following problem. I generate some content which is ~200 bytes in size. I am able to skip the generation of a specific byte index. I would like to make usage of this in order to not generate the content all over again for each block. I use the start and end of coap_block_slicer_t in order to get the information about the current block. I copy the data from it in the beginning of my handler. I count a cur value up until I reach the desired position, so that I can start sending the bytes until I reach the end of the block where I can stop sending more bytes. My initial though was to use something like this:
if(slicer->cur >= slicer->start && slicer->cur < slicer->end){
receiver(&string[i]);
}
Unfortunately this does not work. I tried slicer->cur >= slicer->start && slicer->cur <= slicer->end as well, even though it didn’t make much sense to me. At least this return the first block, but not the next blocks.
Maybe I get a wrong understanding on how the blockwise transfer works. I log out the sent bytes and I observed a behavior I don’t understand.
slicer->cur >= slicer->start && slicer->cur <= slicer->end
2020-09-27 16:32:59,110 # ====== Handler ==========
2020-09-27 16:32:59,112 # Start: 0
2020-09-27 16:32:59,112 # End: 16
2020-09-27 16:32:59,113 # Current: 0
2020-09-27 16:32:59,115 # Send char: Position 0 char {
2020-09-27 16:32:59,118 # Send char: Position 1 char "
2020-09-27 16:32:59,121 # Send char: Position 2 char @
2020-09-27 16:32:59,123 # Send char: Position 3 char c
2020-09-27 16:32:59,126 # Send char: Position 4 char o
2020-09-27 16:32:59,128 # Send char: Position 5 char n
2020-09-27 16:32:59,131 # Send char: Position 6 char t
2020-09-27 16:32:59,133 # Send char: Position 7 char e
2020-09-27 16:32:59,136 # Send char: Position 8 char x
2020-09-27 16:32:59,139 # Send char: Position 9 char t
2020-09-27 16:32:59,141 # Send char: Position 10 char "
2020-09-27 16:32:59,144 # Send char: Position 11 char :
2020-09-27 16:32:59,146 # Send char: Position 12 char [
2020-09-27 16:32:59,149 # Send char: Position 13 char "
2020-09-27 16:32:59,151 # Send char: Position 14 char h
2020-09-27 16:32:59,154 # Send char: Position 15 char t
2020-09-27 16:32:59,157 # Send char: Position 16 char t
2020-09-27 16:32:59,261 # ====== Handler ==========
2020-09-27 16:32:59,262 # Start: 16
2020-09-27 16:32:59,263 # End: 32
2020-09-27 16:32:59,264 # Current: 0
2020-09-27 16:32:59,266 # Send char: Position 16 char t
2020-09-27 16:32:59,269 # Send char: Position 17 char p
2020-09-27 16:32:59,272 # Send char: Position 18 char s
2020-09-27 16:32:59,274 # Send char: Position 19 char :
2020-09-27 16:32:59,277 # Send char: Position 20 char /
2020-09-27 16:32:59,280 # Send char: Position 21 char /
2020-09-27 16:32:59,282 # Send char: Position 22 char w
2020-09-27 16:32:59,285 # Send char: Position 23 char w
2020-09-27 16:32:59,287 # Send char: Position 24 char w
2020-09-27 16:32:59,290 # Send char: Position 25 char .
2020-09-27 16:32:59,293 # Send char: Position 26 char w
2020-09-27 16:32:59,295 # Send char: Position 27 char 3
2020-09-27 16:32:59,298 # Send char: Position 28 char .
2020-09-27 16:32:59,300 # Send char: Position 29 char o
2020-09-27 16:32:59,303 # Send char: Position 30 char r
2020-09-27 16:32:59,305 # Send char: Position 31 char g
2020-09-27 16:32:59,309 # Send char: Position 32 char /
>./coap-client -m get coap://[fe80::fab6:41ff:fe43:b5ab%bt0]/
{"@context":["ht/
So, the first bytes of the second block don’t get returned, while the 32 byte is in the response.
slicer->cur >= slicer->start && slicer->cur < slicer->end
2020-09-27 16:32:11,660 # ====== Handler ==========
2020-09-27 16:32:11,661 # Start: 0
2020-09-27 16:32:11,662 # End: 16
2020-09-27 16:32:11,663 # Current: 0
2020-09-27 16:32:11,665 # Send char: Position 0 char {
2020-09-27 16:32:11,667 # Send char: Position 1 char "
2020-09-27 16:32:11,670 # Send char: Position 2 char @
2020-09-27 16:32:11,672 # Send char: Position 3 char c
2020-09-27 16:32:11,675 # Send char: Position 4 char o
2020-09-27 16:32:11,677 # Send char: Position 5 char n
2020-09-27 16:32:11,680 # Send char: Position 6 char t
2020-09-27 16:32:11,682 # Send char: Position 7 char e
2020-09-27 16:32:11,685 # Send char: Position 8 char x
2020-09-27 16:32:11,688 # Send char: Position 9 char t
2020-09-27 16:32:11,690 # Send char: Position 10 char "
2020-09-27 16:32:11,693 # Send char: Position 11 char :
2020-09-27 16:32:11,695 # Send char: Position 12 char [
2020-09-27 16:32:11,698 # Send char: Position 13 char "
2020-09-27 16:32:11,701 # Send char: Position 14 char h
2020-09-27 16:32:11,703 # Send char: Position 15 char t
If I use slicer->cur <= slicer->end I get the desired response. But it would be nice to skip the first bytes and not send them again.
I haven’t looked into the raw packets yet, but that is the next step. Maybe somebody can just explain me my misunderstanding here. I haven’t read the blockwise RFC for CoAP yet.