Re: Status of Blockwise Transfers
Dijk, Esko <esko.dijk <at> philips.com>
2011-11-04 11:00:32 GMT
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:kovatsch <at> inf.ethz.ch]
Sent: Monday 31 October 2011 20:24
To: Likepeng; Dijk, Esko; core <at> ietf.org
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.
Re the number of options, I now have yet another proposal (too late for the draft deadline):
2.1.4. Alternative: Going to a delimiter model
Another alternative is to spend the additional byte not as an
extended count, but as an option terminator.
In this proposal setting OC to 15 means that the number of options is
no longer given explicitly. Instead, the sequence of options is
terminated by a byte with a special interpretation, 0xF0. (Note that
the option _delta_ of 15 is made special, not any specific option
number.) The next byte is then the first byte of the payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | 15 | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
RSS Feed