Re: [leshan-dev] cancelling a queued request

["Hudalla Kai (INST/ESY1)" <Kai.Hudalla@xxxxxxxxxxxx>]

Thanks for clarifying this, Bala.
I am totally fine with starting off with the cancel operation (which we
need anyways, I guess) :-)

Kai

On Mo, 2016-07-25 at 10:16 +0000, Azhagappan Balasubramanian
(INST/ECS4) wrote:
> Hi Kai,
> 
> We had discussed about TTL before thinking about cancelling a
> request. Even though it looks simple at first, it adds complexity
> depending upon how it can be achieved. IMO, TTL requirements differs
> from one application to another.
> 
> Say, 
> - one might require TTL to be an absolute time. As many systems could
> be involved like message broker, Northbound API, Leshan etc., it
> would make sense to use an absolute time. But it requires all systems
> to be in time synced.
> - TTL can be a relative time. For ex. Relative to when Leshan has
> received the message.
> - TTL doesn't guarantee that on expiry the message is not sent to a
> LWM2M client. i.e:- It could have been valid at the time of delivery
> but before the response has arrived, TTL has expired.
> - TTL can also be realized based on retry count. For ex. After 10
> retries the message is removed automatically.
> 
> Considering the complexity of TTL, we thought of having cancelling a
> request as the first step and build TTL based on that if really
> necessary or one could also leave the entire TTL handing to the
> application layer and let it use this cancel request method.
> Also such a cancel request is not necessarily only for TTL's use case
> but can also be used to rollback any message queued previously.
> 
> Regards,
> Bala
> 
> -----Ursprüngliche Nachricht-----
> Von: leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@eclips
> e.org] Im Auftrag von Hudalla Kai (INST/ESY1)
> Gesendet: Freitag, 22. Juli 2016 17:45
> An: leshan-dev@xxxxxxxxxxx
> Betreff: Re: [leshan-dev] cancelling a queued request
> 
> Is there a particular reason why you want to be able to explicitly
> cancel a request instead of e.g. just being able to set a TTL on the
> request so that it "automatically" is removed from the queue if it
> expires?
> 
> --
> 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
> 
> 
> On Fr, 2016-07-22 at 14:54 +0000, Azhagappan Balasubramanian
> (INST/ECS4) wrote:
> > 
> > Hello,
> >  
> > Now that we have the concept of requestTicket associated with each 
> > request and response in Leshan, I have a specific request. I would 
> > like to create a PR to add cancelRequest(requestTicket) method in 
> > LwM2mRequestSender interface.
> >  
> > I checked the LWM2M spec and it doesn’t say anything or prohibits
> > from 
> > cancelling a queued message. Yes of course with cancellation, the 
> > sequence of messages queued for the LWM2M client is effectively 
> > altered, which in my opinion, is exactly what the application
> > layer 
> > would expect if it invokes this method. Also there is one
> > potential 
> > risk that a message even though cancelled on LWM2M/CoAP level,
> > could 
> > already be delivered or on the wire to the LWM2M client in which
> > case 
> > the response would be ignored.
> >  
> > Is there anyone in the community against such a PR? If yes, I would
> > be 
> > glad to hear your side of the argument. Thanks.
> > Regards,
> > Bala
> >  
> > _______________________________________________
> > leshan-dev mailing list
> > leshan-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or 
> > unsubscribe from this list, visit 
> > https://dev.eclipse.org/mailman/listinfo/leshan-dev
> _______________________________________________
> leshan-dev mailing list
> leshan-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit https://dev.eclipse.org/mailman/lis
> tinfo/leshan-dev
> _______________________________________________
> leshan-dev mailing list
> leshan-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/leshan-dev