Sharing Secure Channel between Sessions #1234
Replies: 2 comments 4 replies
-
|
I just ask the other way round: Does the opc ua spec support such a behaviour? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the late response, thanks for the question. At any rate, the spec doesn't contradict the concept. I've checked at least the Service spec about Sessions, there the only demand is that a Session should be bound to exactly one Secure Channel, but not the other way round, and to abort a session if the Secure Channel changes outside a formalized renewal procedure. Effectively they specified neither that it's prohibited, nor that it is required. |
Beta Was this translation helpful? Give feedback.
-
|
what is the benefit of having two sessions in one client instance? each opc ua server has a limit number of sessions he can support (according to the serverprofile)! |
Beta Was this translation helpful? Give feedback.
-
|
Giving examples... Less physical network connections, for one thing. Less handshakes to negotiate the encrypted transmission for. The ability to use sessions with different roles simultaneously over the same connection without having to reconnect one session with different credentials all the time. Shortened protocol for higher throughput if you're, for reasons, confined to one secure channel at a time. |
Beta Was this translation helpful? Give feedback.
-
|
looking in ua_client.py it looks possible to have multiple sessions from the low-level-api (tbh have not tested it) so it would be an high-level-api thing... just loud thinking! still thinking about the benefit of having multiple connections with different users to one server
technically nothing!
if i rember right the high-level-api was designed to be easy to use and maybe no one has ever needed more then one session ^^ could be an leftover if you add sessions from the low-level-api so you have a session count... |
Beta Was this translation helpful? Give feedback.
-
|
I never heard of that and I ae no interest in implementing this. If I had time I would implement UDP and json/http protocol |
Beta Was this translation helpful? Give feedback.
-
Inspired by the feature list discussion, I've a question for the veteran developers on this project.
From the client code, at a first glance it looks like the plan once existed to support channel sharing (i.e. multiple sessions per secure channel): the client instance has a session counter, at least. So when I first saw the code, I thought the plan might exist. Where there is a counter, there's something to count.
However, the only use the session counter seems to have is default-naming the session.
Is there anyone planning to introduce channel sharing? If you do, do you have any experience or advice for someone who'd dare to work on this?
I've been having threading issues with the server every once in a while, so could imagine it's quite nontrivial to juggle the requests from multiple sessions on one socket. Not to mention threading, properly shutting down half-opened sessions, and closing the secure channel (primarily the socket) when the last session shuts down. Does the test environment somehow lend itself to testing multi-client scenarios that way? Or would that just open the next big construction site?
Do you think an implementation doable at all for python-opcua? Perhaps the asyncio project is a bit more convenient when it comes to multithreaded applications. I'm mostly starting the discussion here because I'm more experienced with this repo's code.
Beta Was this translation helpful? Give feedback.
All reactions