[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Do you use CoapClient API?
|
About the proposition, I'm not sure to see how this will simplify the
code. The response delivery is just a little part of the code
modification and changing the ServerMessageDeliverer will not change the
fact that we will not keep in memory the original request (and so
MessageObservers). But I'm curious to see the code corresponding to this
proposition :)
Le 15/04/2016 16:16, Hudalla Kai (INST/ESY1) a écrit :
Hi Simon,
I would like to pick up on this after having spent almost two days thinking about the fail over support for observations in Californium.
I see two main usage scenarios how Californium is used:
1) A client uses the CoapClient helper class to access (and observe) remote CoAP resources.
The client's intention is NOT to host resources itself. I think this is the main scenario that the CoapClient has been intended to be used for which is e.g.
reflected by the fact that the CoapClient will instantiate a CoapEndpoint dynamically and bind it to an arbitrary port if no endpoint is set explicitly before sending
requests.
In this usage scenario there is no expectation that notifications for observations sent by the remote peer will reach the client after it has crashed (simply because in this case there is no
other client to fail over to). Californium and CoapClient in particular have not supported fail over of observations for this scenario so far and I think we do not need to add any
special support for it in CoapClient in the future. The existing functionality for registering a CoapHandler when sending a request that gets notified about any responses is sufficient and
there is no need to change any of it.
Under the hood Californium registers a MessageObserver with the original request which is called back by the CoapEndpoint's ClientMessageDeliverer once a response (e.g. a notification) for the request arrives from the peer.
2) A client hosts resources and accesses (and observes) resources on other peers.
In this scenario we are usually talking about a server component (like leshan) that hosts CoAP resources to be accessed by other peers but also accesses resources on other peers as well.
Leshan for example accesses and observes resources hosted by LWM2M clients that register with the leshan server.
In this case it would be great if Californium would support failing over of observations (initiated by the leshan server) to another node. The expectation would be that a response sent e.g. by a LWM2M client in response to an observe request originating from server node A can be processed by server node B after node A has crashed and the client has re-connected to node B.
Californium does not support this (yet) because the forwarding of notifications is based on MessageObservers registered with the original Request object. It is obvious that this mechanism cannot work anymore once the original Request object (and thus the registered MessageObservers) is lost once server node A has crashed. In order to be able to fail over to another node the relevant observation state needs to be shared among the server nodes.
However, in case of a fail over the original CoapClient object that was used to create the observation on server node A also does not exist anymore (because server node A has crashed) and can therefore not be notified about notifications now being received on server node B. It therefore simply doesn't make any sense to use CoapClient in such scenarios and we should provide an alternative API in Californium that can be used to send requests and register a generic listener for ALL notifications received by an endpoint.
What I propose
I think we should handle these two usage scenarios separately. In the latter scenario, I do not see the need to allow for client code being able to use both APIs (CoapClient and generic) simultanously. We could therefore simply make the CoapEndpoint's ServerMessageDeliverer's behavior configurable and e.g. make it forward incoming responses to a generic listener instead of invoking the request object's MessageObservers. This way we could keep the request & response processing code within the Matcher and other layers of the CoapStack much simpler than what is currently implemented in the observe_clustering branch (in fact I think we would need to change little more than adding the code for sharing the observation state).
Regards,
Kai
________________________________________
Von: cf-dev-bounces@xxxxxxxxxxx [cf-dev-bounces@xxxxxxxxxxx]" im Auftrag von "Simon Bernard [contact@xxxxxxxxxxxxxxx]
Gesendet: Donnerstag, 14. April 2016 18:39
An: Californium (Cf) developer discussions
Betreff: [cf-dev] Do you use CoapClient API?
Hi,
A recent discussion[1] around clustering support for observe reveals
some limitation with the CoapClient API.
This bring us to the question: should we deprecate this API ?
We would like feedbacks from committers and community to help use to
answer to this question.
Simon
[1]https://github.com/eclipse/californium/pull/16#discussion_r59566651
_______________________________________________
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
