Subject: [core] Status of Blockwise Transfers

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 25 Oct 2011 11:00:18 +0000

Dear Carsten

I would like to ask about the current status of blockwise transfers:

- Concurrent usage of Block1 and Block2 in a single operation
  core-block-04 mentions it once, but does not specify how to handle it or give an example (I guess, a POST request keeps the Block1 option with M=0 and no payload until all Block2 blocks were requested?).

- Using Status codes before an atomic Block1 transfer is complete
  A POST could result in different actions, thus the server cannot provide it before the last Block1 request. Shouldn't the status be empty  when M=0 in a Block1 response?

Thanks a lot
Matthias

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 31 Oct 2011 11:07:43 +0000

Dear Matthias,

I agree with your second point that a server can't in general select a status code to a blockwise POST. It could be either 2.01, 2.02 or 2.04, or one of the error codes, but this depends on the entire payload being POSTed which is only known after the last block (Block1). Perhaps the server could send a "most likely to happen" response code. This is okay since only the final response status code (where M bit 0 in the Block1 option) actually carries the result of the REST operation  - see string "final response" in the text.

The current spec seems to already take this "most likely to happen" meaning for the status code in the examples, e.g. blockwise PUT returns 2.04 each time but if a block is missing the final result could still be 2.04 or 4.00 or 4.08. POST could do the same?

On your first point, concurrent Block1/Block2 usage, that seems only applicable to POST or doesn't it? It seems logical to me that the server can only start sending a blockwise response back (using Block2) when the full payload to POST has been received from the client (who uses Block1 and simultaneously empty Block2 to indicate size) and processed. For this text and/or examples are needed in my view.

regards,
Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kovatsch Matthias
Sent: Tuesday 25 October 2011 13:00
To: Carsten Bormann; [email-masked]
Subject: [core] Status of Blockwise Transfers

Dear Carsten

Thanks a lot
Matthias
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Likepeng <[email-masked]>
Date: Mon, 31 Oct 2011 18:17:54 +0000

> On your first point, concurrent Block1/Block2 usage, that seems only applicable to POST or doesn't it?

From the spec, only concurrent POST is mentioned. In the Size extension draft, I proposed to get the resource size by the Size option, and use concurrent GET for blocks.
http://www.ietf.org/id/draft-li-core-coap-size-option-02.txt

And also I proposed to merge the Size draft and Block draft to allow this, and also other features.

Kind Regards
Kepeng
________________________________________
发件人: [email-masked] [[email-masked]] 代表 Dijk, Esko [[email-masked]]
发送时间: 2011年10月31日 19:07
到: Kovatsch Matthias; [email-masked]
主题: Re: [core] Status of Blockwise Transfers

Dear Matthias,

regards,
Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kovatsch Matthias
Sent: Tuesday 25 October 2011 13:00
To: Carsten Bormann; [email-masked]
Subject: [core] Status of Blockwise Transfers

Dear Carsten

Thanks a lot
Matthias

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Mon, 31 Oct 2011 19:24:29 +0000

Thanks for the responses!

> > The current spec seems to already take this "most likely to happen" meaning
> > for the status code in the examples, e.g. blockwise PUT returns 2.04 each
> > time but if a block is missing the final result could still be 2.04 or 4.00 or 4.08.
> > POST could do the same?

But what is most likely to happen?
The author of the server implementations will just arbitrarily pick a status code, which still has no meaning.
A badly written client then might misinterpret that intermediate status. I think, it only creates a source of errors.

> From the spec, only concurrent POST is mentioned.

Yes, that is how I understand it as well. A successful PUT would always results in resource state, i.e., no payload in the response.

> In the Size extension draft, I proposed to get the resource size by the Size option, and use concurrent GET for blocks.

I would say an upper bound (sz attribute) is enough. Embedded devices usually avoid dynamic memory allocation and those which use it probably have plenty of memory from a CoRE point of view.
For the concurrent GETs, one should be careful not to re-invent/implement TCP (sliding window for messages in flight), I guess. If it is required, the devices should rather switch to another protocol, shouldn't they?
I also saw that even for the server it can be hard to know the exact size in advance. With content-negotiation, the representation is created on-the-fly from some variables. When including on-demand sensor readings, the server cannot even do a "dry run" to pre-cache the sizes for each content-type.

Best regards
Matthias