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.
Le 27/04/2016 18:32, Kovatsch Matthias a
écrit :
Dear
Simon
I tried to be more specific in the GitHub pull-requests. I
don't see much a problem in how the API works, but how the
concepts of the protocol are applied. Let me try to
summarize inline:
It seems we all agree that we have an
internal/advanced API (CoapEndpoint, MessageObserver,
....) and a more high level API (CoAPClient) which is
not really adapted to the cluster/fail-over feature.
This is not a problem, this high level API does not
target this use case.
Indeed,
CoapClient could completely ignore everything
connected to the cluster mode. The only requirement is
that everything works as expected when it is disabled
:)
1) My first modification was to change the
internal/advanced API to introduce a new
ObservationStore.
The main modification was:
- Before, the exchange lived all along the observe
relation lifetime.
- Now, we recreate an exchange for each
notification. I mean a new Exchange instance is created
from data stored in ObservationStore each time we
receive a new notification and will be completed/removed
as soon as the notification is handled.
I
agreed on the separate ObservationStore. I understood
that it will have an interface, so it can be backed by
a local implementation similar to the hashmaps we
already have. In cluster mode, it is backed by a class
that connects to an external shared persistence store,
so each node can be made aware of existing Observe
relationships. I don't care if this class creates an
Exchange object every time or actually persists the
original. The Exchange object returned through the
interface must simply have all the information
necessary to process the incoming message locally. As
long you do not remove the entry from the shared
persistence store, I don't see the Exchange as
completed, but it will not be in the local hashmaps
anyway. We will not need it in the Deduplicator
either, if you have a NotificationOrderer further
up...
This means that the first response for an observe
request will be accessible via the MessageObserver of
the original Request, then next notifications will be
available via NotificationListener.
This also means that now we are able to handle several
notifications transfered with block-wised(block2) at the
same time. (as there is now 1 exchange by notification)
I
do not get any of this :(
Why should notifications, which are responses to a
request, go to a different handler? Why would you
handle them differently? This is where the conflict
with CoAP lies...
If you prefer, we can return all
notification via the NotificationListener even the first one.
But the MessageObserver of the originalRequest will always
return only the response of the first exchange as we don't
keep it in memory.
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.
I
think you are violating the eventual consistency
assumption here: CoAP explicitly does not want to
transmit obsolete state updates! Let me forward a nice
text by Carsten Bormann, that he just sent around
today.
Did you mean you will send another mail
with the text or did you forget to give us the link :) ?
I understood we agreed on this part. If this is not
the case, we should keep focus on this.
(I mean ignore the point 2) )
Let's
do that :)
Best wishes
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
|
