Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Terminating sessions on the server
November 5, 2019
14:05, EET
Avatar
stefan.bck
Member
Members
Forum Posts: 5
Member Since:
November 5, 2019
sp_UserOfflineSmall Offline

Hello team,

I am trying to implement a kind of flood control for the server, since I didn’t find this kind of functionality already built in.
The plan is to disconnect any clients that are flooding the server with requests, i.e. whenever they exceed a certain amount of requests per second over a specified amount of time.

My current strategy is to register listeners on the client sessions (using a SessionManagerListener and overwriting the onCreateSession method) that check the number of requests by overwriting the onSessionChanged method.
This seems to be working fine.

However, I was unable to find any functionality that allows to terminate a session/connection with a client from the server side.
So, the obvious question here is:
Did I overlook something, or is this really not possible?

Another question I would like to ask, is if this approach makes sense in your eyes and weather there is another / more elegant approach to this requirement.

Thanks in advance,
Stefan

November 5, 2019
15:20, EET
Avatar
stefan.bck
Member
Members
Forum Posts: 5
Member Since:
November 5, 2019
sp_UserOfflineSmall Offline

Update:
I found the answer to my first question myself.
It seems a session can be terminated from the server side by calling

session.getChannel().close();

I had already tried this before, but did not notice it was working, since the client I tested it with had auto-reconnect enabled (doAutoReconnect defaults to true).

So now that this is working, is there any reason I should be calling

session.getChannel().dispose();

after closing the channel?

Also, I would still like to know, if you would have taken a different path to implementing the required functionality?

Regards,
Stefan

November 5, 2019
15:36, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 982
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Hi,

(I wrote this before seeing your second post)

At least initially I would go with “this doesn’t make sense” option. Some reasons:

(But before that I would like to ask that do you have an actual/real problem scenario you are trying to solve/prevent or this more … theoretical stuff?)

1.
As far as I’m aware, the specification doesn’t consider a flooding scenario (outside of the service calls needed for the initial connection handling) exactly like this (see 3.). I assume here that you mean flood controls as e.g. too many Read service calls per second.

2.
As the specification doesn’t have this (1.), it in turn means no client would be “flood aware”. For example UaClient will usually do around 100 requests when it connects (or at least on the first interaction with UaNodes), which in normal cases the server should of course respond immediately. Additionally e.g. when a PublishResponse is received back a new one must immediately be sent. It would be hard to know what would be too much. And usually if the session would be closed, the usualy way for a client to properly react would be to reconnect (which in practice most likely would end up taking more resources, unless you would block that client). Generally I would say the risk is too high to fail something real. Especially when (3.).

3.
In a normal use-case an OPC UA Server will trust it’s clients (and vise-versa) and no untrusted clients are allowed to connect. Generally this should eliminate most of the problem cases by itself.

4.
(already mentioned in 3. a bit) If a server closes a Session, client will respond by making a new one. The same is if the connection terminates. You would basically need to ban the client either by not trusting it’s certificate anymore or with a firewall if you support None security mode in the server, but generally this is not the case, except for closed networks (shouldn’t be a problem usually here) or public demo servers (in which case you should use a firewall)

However if you really want to close the session manually, currently there is no exactly designed direct public API to do so. But you can do the following steps and it should work:
– Subtype UaServer
– Override protected UaServer.createSessionManager, return a subtyped SessionManager
– Override protected SessionManager.closeSession(NodeId authenticationToken, boolean deleteSubscriptions), (it must call the super impl)
– Store the subtyped SessionManager somehow or cast UaServer.getSessionManager()
– Call the closeSession with Session.getAuthenticationToken() for the NodeId and you probably want to delete the Subscriptions as well (they have different life-cycle from a Session and could be transferred to other Sessions)

November 8, 2019
14:52, EET
Avatar
stefan.bck
Member
Members
Forum Posts: 5
Member Since:
November 5, 2019
sp_UserOfflineSmall Offline

Hello Bjarne,

thank your for taking the time to answer my questions.

I was tasked with implementing this functionality, because we do not have any control over our clients, and want to ensure that one or several malfunctioning clients are not occupying the server by flooding it with service calls, since the server has the requirement of being highly available. Unfortunately this is not something we can solve through a firewall.

Anyways, I thank you again for your thorough explanation on the steps required to implement this. I already finished the implementation and it is working like a charm (yes, clients are being blocked for some time after flooding the server).

Regards,
Stefan

November 8, 2019
15:48, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 982
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Ok, just note that I would then recommend very clearly documenting the fact you are doing something like this as it is non-standard (as far as I’m aware). And if it is non-standard then it means no client can prepare for that, meaning it can cause interop problems, thus not sure if you can really call that as proper OPC UA. IF the application would pass the compliance tests of the OPC Foundation then probably it would be OK.

I would recommend highly consulting the OPC Foundation, as a lot less important things have been added in the specification in the past and lately, so I wouldn’t rule out e.g. some flood controls being added to the OperationLimits node for example. Then clients would have at least some chance of discovering the limits and try to obey them.

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 518

Currently Online:
17 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 135

pramanj: 86

Francesco Zambon: 81

rocket science: 75

ibrahim: 75

Sabari: 62

kapsl: 57

gjevremovic: 49

Xavier: 43

fred: 41

Member Stats:

Guest Posters: 0

Members: 708

Moderators: 16

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1465

Posts: 6252

Newest Members:

christi10l, ahamad1, Flores Frederick, ellenmoss, harriettscherer, shanonhumphreys, KupimotoblokfuB, tamhollander5, paulinafcf, bridgette18l

Moderators: Jouni Aro: 1009, Otso Palonen: 32, Tuomas Hiltunen: 5, Pyry: 1, Petri: 0, Bjarne Boström: 982, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 26, Teppo Uimonen: 21, Markus Johansson: 42, Niklas Nurminen: 0, Matti Siponen: 319, Lusetti: 0, Ari-Pekka Soikkeli: 5

Administrators: admin: 1