Re: [cf-dev] CoAP retransmission on DTLS Fatal Alert ?

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

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