Coap blockwise 传输 : How to map following blocks to initial block/request

Question

假设我有一个客户端想要向服务器发送两个大请求(同时)。

假设第一个有效载荷是“ABCD”，第二个有效载荷是“WXYZ”。

第一个请求的第一个 block 有 messageID=1 和 token=0x1，负载为“AB”，

第二个请求的第一个 block 有 messageID=2 和 token=0x2，负载为“WX”，

第一个请求的第二个 block 具有 messageID=3 和 token=0x3，负载为“CD”，

第二个请求的第二个 block 具有 messageID=4 和 token=0x4，负载为“YZ”。

您可以看到我的目标。如果每个请求的 messageID 和 token 都不同，并且它们的顺序不连续，那么服务器应该如何连接正确的 block ？

这是一个序列图:

   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   |

问题出现在消息 3 上:服务器现在有两个不完整的负载，它如何可靠地将第三个请求映射到正确的负载？它如何知道负载应该是“ABCD”而不是“WXCD”？

分块转账规范仅规定如下:

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.

Answer 1

你是对的，事实上block-wise specs突出显示它并提出解决方法(仅适用于 block2 选项):

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

和:

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