Re: [core] Status of Blockwise Transfers

[Likepeng <[e-mail]>]

Hello Matthias,

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

Sometimes, the resource will be changed a lot after the resource discovery.

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

Agree. We don't want to re-invent/implement TCP sliding window. I have no intention to propose to add the concurrent GET function, just to say, if people want to implement this feature, here is something that would be useful.

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

I agree that sometimes it is difficult to know the size in advance, but in most of the cases, it can be known.

Thanks,
Kind Regards
Kepeng
________________________________________
发件人: Kovatsch  Matthias [[e-mail]]
发送时间: 2011年11月1日 3:24
到: Likepeng; Dijk, Esko; [e-mail]
主题: 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