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
|