[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Do you use CoapClient API?
|
Hi all
I definitely have to catch up on this topic! Sorry for the long "downtime" :/
First:
I definitely use CoapClient in most of my projects and from what I saw, many other do as well. There, the scenario is pretty much what Kai described! The idea of CoapClient was to have a convenient API to enable quick interactions from a client endpoint. When it fails, it has to start over completely and on its own. It was never intended for "service provider" implementation. This is already reflected in the rather crappy error handling support (which I would like to improve at some point in fact).
The idea was to be able to add additional APIs next to the CoapClient. The MessageObserver is (as already indicated in my other e-mail) an internal API. Projects that know what they are doing can also use it directly (as Leshan does). Maybe, the Leshan way turns into a best practice at some point, at which we could think about moving an alternative "service provider API" from Leshan to Californium.
Second:
I see Achim's point about the underlying design of Observe. The original idea is that a client re-registers when something goes wrong, e.g., when there are no more notifications. If a monitor service can notice a client crash, it could also hand the request initiative over to another client, which then registers to continue the original task of observing the resource.
(Based on how I understood the situation now:) The current design tries to do this in a transparent way, so that the server does not even recognize the handover. It is a different philosophy, but it is not wrong. However, this special philosophy should not affect the normal APIs, which should reflect the common understanding of CoAP's design rationale. Thus, I think Kai's proposal with the configuration approach is quite good.
Would someone maybe be so kind to summarize the current status? There is a lot of discussion cluttered over the issue comments, code comments, and the mailing list... :o)
As I understood it, Simon's proposal is in https://github.com/eclipse/californium/tree/observe_clustering and Kai's proposal in https://github.com/eclipse/californium/tree/observe_clustering_alt and we should make a decision soon to merge this, so Leshan can benefit from it.
Ciao
Matthias
> -----Original Message-----
> From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Hudalla Kai (INST/ESY1)
> Sent: Mittwoch, 20. April 2016 17:29
> To: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
> Subject: Re: [cf-dev] Do you use CoapClient API?
>
> I have pushed my proposed approach to branch "observe_clustering_alt" and
> have created a PR.
> The main difference is that no changes to CoapClient have been made and the
> NotificationListener is only used for delivering notifications.
>
> @Simon: I have incorporated (and refactored) a lot of the testing code from the
> observe_clustering branch but I still think that it is a little more lightweight ... ;-
> )
>
> Mit freundlichen Grüßen / Best regards
>
> Kai Hudalla
> Chief Software Architect
>
> Bosch Software Innovations GmbH
> Schöneberger Ufer 89-91
> 10785 Berlin
> GERMANY
> www.bosch-si.com
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
> 148411 B;
> Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
> ________________________________________
> Von: cf-dev-bounces@xxxxxxxxxxx [cf-dev-bounces@xxxxxxxxxxx]" im
> Auftrag von "Kraus Achim (INST/ESY1) [Achim.Kraus@xxxxxxxxxxxx]
> Gesendet: Montag, 18. April 2016 10:01
> An: Californium (Cf) developer discussions
> Betreff: Re: [cf-dev] Do you use CoapClient API?
>
> Hi all,
>
> so also my 2 cent's:
> Trying to understand this discussion and the discussion in
>
> https://github.com/eclipse/californium/pull/16
>
> my impression/summary is:
> It seems to be rather complex to make a "CoAP observe RFC 7641" working in a
> cluster.
> (And I even didn't understand all details ...) This may be caused by the design of
> the observe (extended request with multiple responses).
> So on the one side, it's just a request, and if a server node fails, the request is
> lost and another server node is the intended to do retry of the request (as for
> any other request).
> On the other side, it may be considered as an extended request working long
> term stable.
> And that introduces a lot of implications. "Solving" them, seems to be too
> complex for me.
> (But I'm sure looking forward, to watch the experiment to do so :-) )
>
> So I would propose not to "extend" the observe and leave the CoAP layer as it is
> (with pro's simplicity over neg's "suitable for all").
> Any "long term/clustering" stuff is then left to the next layer (e.g. LWM2M).
> At those layers it seems to be rather easier to define mechanisms with "long
> term/clustering"
> stability. For e.g. LWM2M, the "update registration" could be extended to
> provide also updates for resource values. This would also solve the "endpoint
> address" change stuff (OK, for DTLS there will still be something to do).
>
> 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
>
>
> Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] Im
> Auftrag von Simon Bernard
> Gesendet: Freitag, 15. April 2016 18:19
> An: Californium (Cf) developer discussions
> Betreff: Re: [cf-dev] Do you use CoapClient API?
>
> I can not see a good way to keep the orginal request in memory (in
> exchangesByToken) which will allow to implement observation cancelling
> easily. [1] (Currently, Leshan we are mainly interested by the response, I don't
> know for the future)
>
> [1]https://github.com/eclipse/californium/pull/16#commitcomment-16503803
> Le 15/04/2016 18:03, Kai a écrit :
> I guess the point I am trying to make is that we can safely keep the original
> request in memory (in the exchangesByToken map). However, I see a different
> problem with what I have proposed: it does not (by its own) provide a way to be
> notified about observation life-cycle events other than notifications. But i guess
> that is what you are also interested in for leshan, aren't you?
>
> On Fri, Apr 15, 2016 at 4:41 PM Simon Bernard <contact@xxxxxxxxxxxxxxx>
> wrote:
> 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
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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
