Re: [cf-dev] DTLSConnector Start/Stop

["Kovatsch Matthias" <kovatsch@xxxxxxxxxxx>]

Hi Simon

Due to a conference I am quite late with my reply... sorry.

Start/stop is not only intended for testing. Other frameworks often provide this feature and we thought it might be useful. However, we did not have a clear use case in mind. Things imagined where dynamically adding an endpoint to a running server, for instance, with a 6LoWPAN-compressable UDP port or an SMS endpoint that is not required all the time.

I assume this discussion is about Californium and not CoAPS nodes in general, although the descriptions (also by Kai) were pretty generic :)

My idea would be to clear the ConnectionStore only on destroy(), which frees all the resources.

stop() and start() is basically the idea of suspending and resuming. So I would set resumptionRequired to true for all connection on stop().
It would also good, if we could free some of the resources on stop().
A constrained device going to sleep should not stop its endpoint, so no re-handshake (unless the address changed, which would imply creating a new endpoint, since not sure if the wildcard address can handle this...)

I don't see how a UDP "connection" can break down. If an interface disappears, there will be an exception. I think we have to improve the handling of this to allow for appropriate recovery actions.
In case of a crash, I assume a complete restart of the framework, so nothing to do for us.

Ciao
Matthias

> -----Original Message-----
> From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Simon Bernard
> Sent: Mittwoch, 21. Oktober 2015 18:07
> To: Californium (Cf) developer discussions
> Subject: [cf-dev] DTLSConnector Start/Stop
> 
> Hi,
>    I encountered a strange behavoir with a start/stop method.
>    I create an endpoint with dynamically assigned port (new
> InetSocketAddress(InetAddress.getLoopbackAddress(), 0))
>    I start it, a port is assigned to it.
>    I send request to a server (new DTLS session is established)
>    I stop it, then I restart it and a new port is assigned to it.
>    I try to send a new request to the same server, as the Connection store still
> contains the connection to this peer, the corresponding established session
> will be used.
>    But the IP port changed, so at server side there is no connection for this
> peer, so the Application Data  will be ignored by the server ...
> 
>    I don't know what could be the right fix to this ? I'm not sure to know the
> purpose of start/stop. In my case that was to simulate a reboot of a device
> but I suppose recreate a new client should be better to simulate that.
>    I suppose we can imagine that :
>     a) we clear the ConnectionStore on stop().
>     b) clean connectionStore at start if the inetAddress changed.
> (overkill?)
>     c) set resumptionRequired to true for all connection on stop(), to force a
> session resumption at first communication.
>     b) set resumptionRequired to true for all connection only if the
> inetAddress changed ( overoverkill ??)
> 
>    I'm not sure there is another use case than testing for start/stop, so I
> suppose the a) is enough ?
> 
> 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