Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cf-dev] Scandium connection resumption vs. renegotiation
About connection store even if this could do the job to return only the first connection for a particular sessionID, this is not really relevant as API since we said that for a sessionID we can have several connection ... And this will not be so easy to implement the Alert stuff without this.

So in a general way, I agree we should do that if we want to respect the spec which say that a session could be shared between several connection.
But I'm not sure we have real use case for now. So I prefer we don't support session sharing than implement it partially.
We should probably wait to see if there is needs about that.

Le 24/02/2016 16:32, Hudalla Kai (INST/ESY1) a écrit :

Very good point, Simon.

However, I think InMemoryConnectionStore supports keeping multiple Connections having the same session ID. Also, if a client wants to use an existing connection’s state to negotiate a new connection based on the session ID, then it is irrelevant which of the (potentially) multiple existing Connections sharing this same session ID is returned by ConnectionStore.find(sessionID). In particular, the first matching Connection is fine.

 

What we currently do not support though, is what you dug out from the sepc regarding Alert handling. That is something we would need to add.

 

But would you in general agree that we should change Scandium’s behavior according to my previous mail, i.e. keep the existing connection intact and let it time out (or not if the client keeps using it)?

 

Kai

 

 

From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Bernard
Sent: Wednesday, February 24, 2016 4:19 PM
To: Californium (Cf) developer discussions
Subject: Re: [cf-dev] Scandium connection resumption vs. renegotiation

 

Makes sense to me.
But this will involve more modification than that. I think in the current implementation we don't share session through connection.
The current connection only returns 1 connection for a given sessionID.
We should also mange this kind of thing :
"Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier MUST be invalidated, preventing the failed session from being used to establish new connections."[1]

We must see if we want to support sharing session before to do that.

[1] https://tools.ietf.org/html/rfc5246#section-7.2

Le 24/02/2016 13:41, Hudalla Kai (INST/ESY1) a écrit :

Hi Achim,
 
You are right, the server cannot really "recognize" this. Scandium currently "implicitly deduces" that this is the case from the fact that the client indicates the session ID of the previously established connection. However, this also means that a client currently cannot create an additional connection to the server based on an existing connection. I think we should change this behavior so that the server simply negotiates the additional connection with the client based on the existing connection and let the client decide whether it wants to continue to use both connections (old and new) or just the newly created connection. In the latter case the existing connection will simply time out on the server side and be "garbage collected".
 
Does that make sense?
 
Regards,
Kai
 
 
-----Original Message-----
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On Behalf Of Kraus Achim (INST/ESY1)
Sent: Wednesday, February 24, 2016 1:10 PM
To: Californium (Cf) developer discussions
Subject: Re: [cf-dev] Scandium connection resumption vs. renegotiation
 
Hi,
 
the wiki page mentions:
 
"The DTLSConnector running on the server side will recognize that the client's IP address/port has changed and will silently discard the previously established connection after the handshake has completed."
 
How does the server identify the client (to discard the old connection), if it could not use the address/port because this changed?
 
Mit freundlichen Grüßen / Best regards
 
Achim Kraus
 
Bosch Software Innovations GmbH
Communications (INST/ESY1)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com 
 
achim.kraus@xxxxxxxxxxxx
 
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
 
 
 
-----Ursprüngliche Nachricht-----
Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] Im Auftrag von Hudalla Kai (INST/ESY1)
Gesendet: Mittwoch, 24. Februar 2016 11:47
An: Californium (Cf) developer discussions
Betreff: [cf-dev] Scandium connection resumption vs. renegotiation
 
Hi,
 
Simon and I have been discussing for some time now about when and how a client would want to reconnect to a server and how these use cases are to be implemented according to the DTLS spec.
 
I have created a Wiki page [1] identifying some relevant real world use cases we would like to cover with Scandium. I would now like to use this thread to discuss the use cases and then gradually add information to the Wiki page so that we get a consistent picture over time and do not lose information.
 
So if you have any opinion regarding this topic I would be glad if you joined this thread :-)
 
[1] https://github.com/eclipse/californium/wiki/DTLS-Connection-Renegotiation-vs.-Resumption
 
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
_______________________________________________
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

Back to the top