[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] DTLSConnector Start/Stop
|
That sounds good :)
I take look at the code to do that we need a way to iterate on all
connections of the store.
Simon
Le 22/10/2015 09:00, Hudalla Kai (INST/ESY) a écrit :
Yes, you are right. We should fix this more thoroughly. It looks like we need to deal with different situations/use cases:
1) a client that is not very constrained regarding battery and networking
2) a constrained client that sleeps most of the time but wakes up periodically to send some data and then goes back to sleep
3) a client that has established a connection but then breaks down due to some unknown reason, restarts and wants to re-connect
For 1) nothing needs to be done. The client simply connects to the server once and uses the connection for its whole lifetime. At some point in time the client decides to disconnect and shutdown. All of this is supported by the current Scandium implementation.
In use case 2) the client will probably want to re-use its existing connection with the server since it is very costly to negotiate a new session (as you and I know best ;-). I think the most interesting question is: does the client stop its DTLSConnector when it goes to sleep or not? Is it necessary for the client to release all sockets it has bound to before it can go to sleep?
If this is the case then the problem you describe might occur if
a) the client gets a new IP address when it wakes up again (e.g. because the client is on a mobile network) or
b) the port it had originally bound to is in use by another process when it wakes up again.
In both cases the right thing to do seems to be what you suggested: either sweeping the client's ConnectionStore or mark all connections "to be resumed" in order to force negotiation of a new session or resumption of the existing session(s). I think we should strive for the latter option for obvious performance reasons. In the start() method we could determine if this is actually a re-start (lastBindAddress != null) and check if we are binding to the same IP address and port and if the bind succeeds. If not, we can mark all connections "to be resumed".
In use case 3) the client may or may not be able to re-use the information from the ConnectionStore (depending on whether the client uses a persistent ConnectionStore or the default in-memory implementation). If it uses the in-memory implementation the client will negotiate a new connection with the server as soon as it tries to send some data. In the other case it is up to the implementor of the ConnectionStore how to deal with the situation, e.g. taking the same approach as outlined for use case 2).
Does this make sense to you, Simon?
Kai
-----Original Message-----
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Simon Bernard
Sent: Wednesday, October 21, 2015 7:07 PM
To: Californium (Cf) developer discussions
Subject: 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
_______________________________________________
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
