Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cf-dev] DTLSConnector Start/Stop
Maybe, make it public could help me, (even if in my case I use a sleep between stop and start method to simulate that the device is not accessible for a while) But this is just a little part of the problem, we still have a stop method which say that we can start the connector again but this doesn't work in this case. 
So we should fix this, right ?
Simon

Le 21/10/2015 18:32, Hudalla Kai (INST/ESY) a écrit :

Hi Simon,

I have added DTLSConnector.restart() for exactly that purpose some weeks ago when I changed the test clients to use ephemeral ports (as you seem to do) :-) However, so far I have only used it in test cases (from within the same package), thus it currently is declared package private. If you want it to be available from client code as well (from other packages), you can change it to be public ...

Kai




-----Original Message-----
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Simon Bernard
Sent: Wednesday, October 21, 2015 6:07 PM
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

_______________________________________________
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