[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] DTLSConnector Start/Stop
|
Matthias & Simon,
some remarks regarding the role and behavior of Scandium in this context...
> My idea would be to clear the ConnectionStore only on destroy(), which
> frees all the resources.
>
I think we can all agree that we can safely clear the ConnectionStore on DTLSConnector.destroy().
I will add this to DTLSConnector.destroy();
> stop() and start() is basically the idea of suspending and resuming. So
> I would set resumptionRequired to true for all connection on stop().
I think we should be a little more optimistic as to whether the client keeps its IP address and can bind again to the same port as before. Thus, I would suggest that we postpone this step to the next invocation of DTLSConnector.start() and do this only if we are not able to re-bind to the same InetSocketAddress as before (which is kept in DTLSConnector.lastBindAddress). This way we will be able to simply continue to use the already established connections in cases where no IP address change/port conflict occurs (which will probably be a lot of cases)
> It would also good, if we could free some of the resources on stop().
We could go through all Connections in the ConnectionStore and check if they have reached the timeout threshold and remove them from the store, thus freeing up some memory. Apart from that we are already closing the socket and clear the outbound message queue.
> 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.
I have to admit that I do not know how java.net.DatagramSocket behaves if it is bound to an InetSocketAddress and the IP address changes or the network interface disappears. We will need to conduct some tests, I guess. Any volunteers? :-)
> In case of a crash, I assume a complete restart of the framework, so
> nothing to do for us.
Agreed :-)
Regards,
Kai
