Re: [cf-dev] Do you use CoapClient API?

["Kraus Achim (INST/ESY1)" <Achim.Kraus@xxxxxxxxxxxx>]

Hi Simon,

> I'm not sure but as we have 2 exchanges in memory and each one use a different token, I guess that the content should not be mixed.
> https://tools.ietf.org/html/draft-ietf-core-block-18#section-3.4

Tokens are just identifying the exchange of on block, 
they don't protect the transfer of the complete resource.

Consider "2.4 Using Block 2 Option" also. See the section explaining the 
"SHOULD" use of ETag assuming "dynamically changing resources". 

And below that even further:

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

Assuming two value versions of the same resource, which one should be returned?
The only identifying artifact is the URI, but this is the same for both
transfers. The token may be changed for each block, so it can't be used to
distinguish.

Resource a, version 0
Changes to version 1
=> notify a) with 1. Block of version 1
GET a) for 2. Block, received 2. Block of version 1
Changes to version 2
=> notify b) with 1. Block of version 2
GET a) for 3. Block, received 3. Block of version 2 
=====> content a) invalid !!!

Therefore, the blockwise GETs for notify a) must be stopped, 
when notify b) is received.

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 

achim.kraus@xxxxxxxxxxxx

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn


-----Ursprüngliche Nachricht-----
Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] Im Auftrag von Simon Bernard
Gesendet: Donnerstag, 28. April 2016 15:24
An: Californium (Cf) developer discussions
Betreff: Re: [cf-dev] Do you use CoapClient API?

Le 28/04/2016 13:15, Kraus Achim (INST/ESY1) a écrit :
> Hi Simon,
> Hi Matthias,
>
> [MK] The result, that this is now possible …
>
> I would say, it "pretends" that is now possible :-).
>
> But though Simon already clarified, that this was not his intention, I'm not sure, if we should continue to discuss the "intention".
>
> Therefore I would like to point more to the details, what happens, if 
> the CoAP client receives two notifies for the same blockwise resource. 
> Without E-Tag option, I would assume, that the first (deprecated notify according the OBSERVE Option) would possible report a "invalid" content (mixedup versions of the resources). So I'm just afraid of invalid content.
I'm not sure but as we have 2 exchanges in memory and each one use a different token, I guess that the content should not be mixed.
https://tools.ietf.org/html/draft-ietf-core-block-18#section-3.4
>
> 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
>
> Tel. +49 711 811-58139
> achim.kraus@xxxxxxxxxxxx
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, 
> HRB 148411 B
> Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
>
>
> Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] Im 
> Auftrag von Kovatsch Matthias
> Gesendet: Donnerstag, 28. April 2016 12:44
> An: Californium (Cf) developer discussions
> Betreff: Re: [cf-dev] Do you use CoapClient API?
>
> From: cf-dev-bounces@xxxxxxxxxxx [cf-dev-bounces@xxxxxxxxxxx] on 
> behalf of Simon Bernard [contact@xxxxxxxxxxxxxxx
>
> Le 28/04/2016 09:10, Kraus Achim (INST/ESY1) a écrit :
>
> Hi Simon,
>   
> ➢  What do you mean by several notifications transfered?
>   
>> This is the case where notifications is sent using blockwised (block2). If you send notification faster then server are able to handle (using block2), you can have several notification handle at the same time. Before as we have only one exchange for all the notifications, we dropped the older notifications. Now we are able to handle several at the same time.
>   
> If a resource, which is transferred blockwise, changes more frequently than you can transfer it, there is no guarantee that you still can read the old one!
> Only the “memory monster approach of californium with its own in 
> memory copy” will do that. For the most embedded devices I would 
> guess, that they could only provided the last version. (The blockwise therefore mentions to use E-Tag option to ensure, that the blocks of the resource belongs to the same version of the resource).
> Just to be clear about this point. This new behavior is not a wish, this is just a consequence. I just try to be exhaustive about the behavior changes.
>
> [MK] The result, that this is now possible is an indicator that the concept behind Observe is now violated. The whole point of Observe is to make state synchronization scalable. Did you have a look at Carsten's mail that I forwarded (Re: Events, Subscriptions, Link Bindings, and RESThooks)?
>
> Best regards
> Matthias
> _______________________________________________
> cf-dev mailing list
> cf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit 
> https://dev.eclipse.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cf-dev