| Re: [cf-dev] Do you use CoapClient API? |
|
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... What do you mean by several notifications transfered? 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. 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 |