[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wakaama-dev] Wakaama block2
|
Thx Achim :)
1) I understand that the RFC7959 say that block2 can be done at
requester initiative or not. I would like to get confirmation that
currently Wakaama support block 2 only at requester initiative ?
2)So, you agree there is a problem with the current implementation ?
I'm not sure using ETAG is the right solution.
2.a) ETAG is not really mandatory.
2.b) As you said this could be difficult to implement because of
object, instance, resource hierarchy
2.c) For changing resources like time or sensor value, we can never
be able to have a constant ETAG.
Maybe a solution could be to use a buffer like we do for block1 ? (this
is less efficient at memory point of view, but it fixes this issue and
avoid to build the whole payload for each blocks)
3)ok, but you confirm there is no support of block2 for notification in
wakaama ?
Simon
Le 01/12/2016 à 10:07, Kraus Achim (INST/ESY1) a écrit :
Hi Simon,
1)
RFC7959, 3.1, Figure 2, starts with GET (without block2 option) and receives a response with block2 option.
2)
RFC7959, 2.4, (at the end of the section, page 13)
"The Block2 Option provides no way for a single endpoint to perform
multiple concurrently proceeding block-wise response payload transfer
(e.g., GET) operations to the same resource."
So in my opinion, the intention was, that there is an "random" accessible implementation of the resource
(e.g. byte array). And a GET just fetches the current value of that resource. If the value has changed, then
ETAG should be used.
On my experience, TLV in LWM2M makes it very difficult to implement such a behavior,
because the "payload" is calculated out of resource representations (e.g. GET on object or instance level). This
ends up in either require to have a also a "byte array" representation or to dynamically calculate the "part".
3)
RFC7959, 2.6
If a notification has a block2 option, this tells the client, that there is more payload.
If the client is interested in the complete payload, it must continue the read the next blocks.
But with changing blockwise content, ETAG should really be considered to be used!
So in my experience, the "easy and effective implementation of blockwise" is really in contrast with the construction of TLV payload.
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ESY1)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
-----Ursprüngliche Nachricht-----
Von: wakaama-dev-bounces@xxxxxxxxxxx [mailto:wakaama-dev-bounces@xxxxxxxxxxx] Im Auftrag von Simon Bernard
Gesendet: Mittwoch, 30. November 2016 18:33
An: Wakaama developer discussions <wakaama-dev@xxxxxxxxxxx>
Betreff: [wakaama-dev] Wakaama block2
Hi all,
I'm looking at the block2 support in wakaama and I have severals questions.
1) It seems thats block2 is used at requester initiative only. Am I right ? if yes, should we also use block2 automatically when the payload is > to REST_MAX_CHUNK_SIZE ?
2) if I well understand the code, we read the full object each time we receive a block2 request ? We could face strange issue if the resource value change between 2 requests ?
(e.g the value change between a request for block 2 and a request for block 3)
3) there is no support of block 2 for notification ?
Thx,
Simon
_______________________________________________
wakaama-dev mailing list
wakaama-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/wakaama-dev
_______________________________________________
wakaama-dev mailing list
wakaama-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/wakaama-dev
