[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] CoAP retransmission on DTLS Fatal Alert ?
|
I need something similar to improve error handling for the CoapClient API.
My rough idea would be to have try/catch around synchronous calls and an Exception parameter for the onError() handler method. Both could use these domain-specific exceptions.
Was there any progress on the RawDataChannel? We should collect all possible domain-specific exceptions we can think of and discuss a common mechanism. For this, I created the following bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=474416
Ciao
Matthias
> -----Original Message-----
> From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Simon Bernard
> Sent: Freitag, 24. Juli 2015 14:56
> To: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
> Subject: Re: [cf-dev] CoAP retransmission on DTLS Fatal Alert ?
>
> that sounds good to me.
>
> Le 24/07/2015 10:17, Hudalla Kai (INST/ESY) a écrit :
> > Thanks, Simon, for opening the bug.
> >
> > As already indicated I agree with you that it is desirable to have Californium
> detect and handle this problem.
> >
> > We need to keep in mind though, that Californium is (currently) not aware
> of the particular transport protocol it is running on top of which I think is a
> good thing. Californium should not need to know about the specifics of a
> DTLS fatal alert. In fact, it shouldn't even (need to) know what DTLS is from
> my point of view.
> >
> > I would therefore suggest that we extend the RawDataChannel in
> element-connector with something like an "onError(Exception)" method and
> a "domain specific" exception hierarchy reflecting the kind of problems we
> anticipate and want to be able to handle. By "domain specific" I mean that
> the exceptions should have a particular meaning instead of just reflecting a
> "general problem at the IP layer". I could imagine something like a
> PeerNotReachableException, ConnectionRefusedException,
> AuthenticationException etc. These exceptions should ideally form a
> reasonable hierarchy so that application code does not necessarily need to
> catch and handle each exception explicitly.
> >
> > What do you think?
> >
> > Regards,
> > Kai
> >
> >> -----Original Message-----
> >> From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
> >> On Behalf Of Simon Bernard
> >> Sent: Wednesday, July 22, 2015 6:37 PM
> >> To: Californium (Cf) developer discussions
> >> Subject: Re: [cf-dev] CoAP retransmission on DTLS Fatal Alert ?
> >>
> >> It's done : https://bugs.eclipse.org/bugs/show_bug.cgi?id=473300
> >>
> >> Le 22/07/2015 12:38, Hudalla Kai (INST/ESY) a écrit :
> >>> Simon,
> >>>
> >>> I totally agree that it should be Californium's responsibility to
> >> detect this kind of failure and notify application layer clients
> >> accordingly. What you suggest makes sense to me at first sight.
> >>> Can you open a bugzilla bug for this that I can refer to when
> >> starting work on it?
> >>> Regards,
> >>> Kai
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: cf-dev-bounces@xxxxxxxxxxx
> >>>> [mailto:cf-dev-bounces@xxxxxxxxxxx]
> >>>> On Behalf Of Simon Bernard
> >>>> Sent: Friday, July 17, 2015 6:26 PM
> >>>> To: Californium (Cf) developer discussions
> >>>> Subject: [cf-dev] CoAP retransmission on DTLS Fatal Alert ?
> >>>>
> >>>> Hi,
> >>>> Currently, when we use Californium and try to send a request
> >>>> through DTLSConnector, if the request failed because of DTLS Fatal
> >> Alert (e.g.
> >>>> bad certificate), this is not visible at californium level. I mean
> >>>> Californium will never know thats something goes wrong, so at CoAP
> >>>> level we don't get a response for the request and we try to
> >>>> retransmit it until CoAP timeout or manual cancellation.
> >>>>
> >>>> I suppose this not really, the expected behavior.
> >>>>
> >>>> With the ErrorHandler class added by Kai in scandium, we can
> >>>> workaround the problem with some gymnastic by cancelling the
> >>>> request when we receive an Alert from the peer we requested. But
> >>>> this could make sense if that was managed by Californium.
> >>>> I think we should not try to retransmit request after a DTLS
> >>>> fatal error and we should add something like onError(String) method
> >>>> on MessageObserver to inform sender that the request failed.
> >>>>
> >>>> I looked at the code the main issues was :
> >>>> 1) add a way to get error from RawDataChannel.
> >>>> 2) retrieve exchange(s?) from address/port only ( we don't
> >>>> have message ID because we don't have CoAP message :p)
> >>>> 3) notify all MessageObserver that the request failed
> >>>> 4) set the exchange(s?) as completed
> >>>>
> >>>> Does it make sense ?
> >>>>
> >>>> Simon
> >>>>
> >>>> _______________________________________________
> >>>> 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
