Subject: [core] Open issues with -block

From: "Kovatsch Matthias" <[email-masked]>
Date: Sun, 13 Oct 2013 19:49:35 +0000

Dear list

I still have some issues with blockwise transfers that I would like to discuss:

1) Change of initiative to the server

As CoAP implementer for constrained devices, I am not happy about this solution, as it requires additional code for servers to manage the active transmission of blocks (cf. Block2 in response to GET is handled differently). The current solution can also not fulfill the in-order requirement for blocks: Block2 #1 is transmitted piggybacked when acknowledging the last Block1 and Block2 #2 is transmitted right after as separate response. In this case, #1 and #2 can get reordered.

2) Combination with Observe

The change of initiative is currently also used when combining -block with -observe. This, however, burdens the server with quite a bit of house-keeping. A while ago, I proposed a different solution, where only the first block is transmitted as notification and then the clients collect the remaining blocks with normal GET requests (running the same code as for normal blockwise GETs). This also fits nicely with the new token-based observe relationships, as there is no risk of accidental cancelling.

3) Response codes for incomplete requests

Currently, servers have to respond to Block1 requests with a status code they cannot know until they received all blocks (especially, when using atomic transfers). The best solution would be to respond with 1.00 Continue, but this code range was not defined in the core draft. The second best thing would then be to assign a 2.xx Block Successful code.

A transmission without change of initiative would look like this:

   CLIENT                                                     SERVER
     |                                                              |
     | CON [MID=1234], POST, /soap, 1:0/1/128      ------>          |
     |                                                              |
     | <------   ACK [MID=1234], 2.xx Block Successful, 1:0/1/128   |
     |                                                              |
     | CON [MID=1235], POST, /soap, 1:1/1/128      ------>          |
     |                                                              |
     | <------   ACK [MID=1235], 2.xx Block Successful, 1:1/1/128   |
     |                                                              |
     | CON [MID=1236], POST, /soap, 1:2/0/128      ------>          |
     |                                                              |
     | <------   ACK [MID=1236], 2.01 Created, 2:0/1/128, 1:2/0/128 |
     |                                                              |
     | CON [MID=1237], POST, /soap, 2:1/0/128      ------>          |
     | (no payload, when Block2 is set)                             |
     | (could also do block size negotiation, requesting 2:0/0/64)  |
     |                                                              |
     | <------   ACK [MID=1237], 2.01 Created, 2:1/1/128            |
     |                                                              |
     | CON [MID=1238], POST, /soap, 2:2/0/128      ------>          |
     |                                                              |
     | <------   ACK [MID=1238], 2.01 Created, 2:2/1/128            |
     |                                                              |
     | CON [MID=1239], POST, /soap, 2:3/0/128      ------>          |
     |                                                              |
     | <------   ACK [MID=1239], 2.01 Created, 2:3/0/128            |

Was there anything speaking against this solution and I just forgot about it?

Please discuss, especially, when you implemented Block1+Block2 POST and the combination of -block with -observe.

Best regards

Matthias