[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] DTLSConnector Start/Stop
|
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
