3

Let's say I have a client that wants to send two large requests to the server (at the same time).

Let's say the first payload is "ABCD" and the second payload is "WXYZ".

First block of first request has messageID=1 and token=0x1 with payload "AB",

First block of second request has messageID=2 and token=0x2 with payload "WX",

Second block of first request has messageID=3 and token=0x3 with payload "CD",

Second block of second request has messageID=4 and token=0x4 with payload "YZ".

You can see where I'm going with this. If messageID and token are different for each request, and they don't follow in consecutive order, how is the server supposed to concatenate the correct blocks?

Here's a sequence diagram:

   CLIENT                                                   SERVER
     |                                                        |
     | CON [MID=1,TOK=1], POST, /foo, 1:0/1/128, "AB" ------> |
     |                                                        |
     | <------   ACK [MID=1,TOK=1], 2.31 Continue, 1:0/1/128  |
     |                                                        |
     | CON [MID=2,TOK=2], POST, /foo, 1:0/1/128, "WX" ------> |
     |                                                        |
     | <------   ACK [MID=2,TOK=2], 2.31 Continue, 1:0/1/128  |
     |                                                        |
     | CON [MID=3,TOK=3], POST, /foo, 1:1/0/128, "CD" ------> |
     |                                                        |
     | <------   ACK [MID=3,TOK=3], 2.01 Created, 1:1/0/128   |
     |                                                        |
     | CON [MID=4,TOK=4], POST, /foo, 1:1/0/128, "YZ" ------> |
     |                                                        |
     | <------   ACK [MID=4,TOK=4], 2.01 Created, 1:1/0/128   |

The problem occurs on message 3: The server now has two incomplete payloads, how can it reliably map the third request to the correct payload? How does it know that the payload is supposed to be "ABCD" instead of "WXCD"?

The specification for blockwise transfer only states the following:

As a general comment on tokens, there is no other mention of tokens in this document, as block-wise transfers handle tokens like any other CoAP exchange. As usual the client is free to choose tokens for each exchange as it likes.

Robert Ende
  • 376
  • 3
  • 11

1 Answers1

4

You are right, in fact the block-wise specs highlight it and propose a workaround (for the block2 option only):

The Block2 option provides no way for a single endpoint to perform multiple concurrently proceeding block-wise response payload transfer (e.g., GET) operations to the same resource. This is rarely a requirement, but as a workaround, a client may vary the cache key (e.g., by using one of several URIs accessing resources with the same semantics, or by varying a proxy-safe elective option).

and:

The Block1 option provides no way for a single endpoint to perform multiple concurrently proceeding block-wise request payload transfer (e.g., PUT or POST) operations to the same resource. Starting a new block-wise sequence of requests to the same resource (before an old sequence from the same endpoint was finished) simply overwrites the context the server may still be keeping. (This is probably exactly what one wants in this case - the client may simply have restarted and lost its knowledge of the previous sequence.)

Jiloc
  • 2,568
  • 3
  • 20
  • 37
  • Thank you very much for your answer, I must have missed it when going through the specs. I was hoping I could use tokens but I guess I will have to enforce having only one blockwise transfer at a time. – Robert Ende Oct 08 '15 at 16:17