Re: [cf-dev] DTLSConnector Start/Stop

[Kiran Pradeep <kiran.happy@xxxxxxxxx>]

Kai,

Some tests on UDP exceptions below.

On 10/28/15, Hudalla Kai (INST/ESY) <Kai.Hudalla@xxxxxxxxxxxx> wrote:
> 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? :-)

Tested UDP exceptions with sample code at
http://pastebin.com/skguskwe. Not sure if this is what was required.
UDP Sender(sample code) was my PC connected to wifi router. UDP
Receiver was a a mobile app.

Case 1: Sender wifi interface turned off during sending and never
turned on again. No exceptions in sender. I kept it for 10 minutes. No
exceptions. Receiver didn't receive any packets.

Case 2:  Sender have static IP. During sending packets, sender's wifi
interface turned off. And turned on after a minute. Receiver continued
to receive all packets except those send during the 1 minute. No
exceptions in sender. It continued to run as if nothing has happened.

Case 3: Sender have dynamic IP. During sending packets, sender's wifi
interface turned off. And turned on after a minute. If sender was a
different by DHCP, SocketException(message: bind failure) is thrown on
sender's DatagramSocket.send() call (line 20).

>
>> In case of a crash, I assume a complete restart of the framework, so
>> nothing to do for us.
> Agreed :-)
>
>
> Regards,
> Kai
>
> _______________________________________________
> 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
>