| Re: [cf-dev] Do you use CoapClient API? |
|
Thx for all this feedbacks :), but I must confess I'm a bit lost. 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. 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. 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 understood we agreed on this part. If this is not the case, we should keep focus on this. (I mean ignore the point 2) ) 2) As I believed the internal/advanced API modification was ok, I tried to change the CoAPClient to make it operational with the new internal/advanced API. (I would like to exclude the notification orderer topic of this point for now, I mean this is probably the next step, but let focus on step 2) ). So It seems this code modification concerning this point was not really appreciate. I have no problem with that, but for now the arguments don't really help me to provide another solution. The main argument is "I don't like it". Does it mean this does not works ? (What does not work ?) Does it mean this is not elegant ? (Any idea to make it more elegant ?) Hope this will help us to move forward. :) Simon Le 22/04/2016 14:04, Kovatsch Matthias a écrit : 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 thinkingabout 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) remoteCoAP resources.The client's intention is NOT to host resources itself. I think this is the mainscenario 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 setexplicitly 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 failover 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 originalrequest 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 otherpeers.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 LWM2Mclients that register with the leshan server.In this case it would be great if Californium would support failing over ofobservations (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 ofnotifications 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 tocreate 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 latterscenario, 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_______________________________________________ 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 |