Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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

Back to the top