Re: [core] Status of Blockwise Transfers

["Dijk, Esko" <[e-mail]>]

Thank you both for your comments.

> 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.

Still, it's not "arbitrarily pick a status code". Even though the intermediate per-block status codes are not the status for the final operation, they're still needed. E.g. if the Nth block of a blockwise PUT returns 4.13 or 5.00 the client knows to stop sending further blocks.
We could look at it in another way: in essence the 2.01 and 2.04 codes from core-coap are re-used by core-block as per-block status codes slightly different meanings:

        2.01  Will Be Created after successfully completing this blockwise operation, Please Continue
        2.04    Will Be Changed after successfully completing this blockwise operation, Please Continue

at least for atomic blockwise PUT/POST. So the codes have some flavour of HTTP 100 Continue as well and an early indication of what would happen.

regards,
Esko

-----Original Message-----
From: Kovatsch Matthias [mailto:[e-mail]]
Sent: Monday 31 October 2011 20:24
To: Likepeng; Dijk, Esko; [e-mail]
Subject: RE: [core] Status of Blockwise Transfers

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.

> > 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.

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.
> http://www.ietf.org/id/draft-li-core-coap-size-option-02.txt

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


________________________________
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.