Hi Niclas, I think the very special problem we have here is the limitation of the number of concurrent connections PLCs usually provide ... my S7 1200 allows 3 concurrent connections. My KNX gateway (which is one of the better models allowing multiple concurrent connections) only allows 4 connections.
So, we really need to find a balance between the number of connections and the features we offer. In the case of KNX we even have the situation that, as soon as you connect to the gateway, you become part of the KNX network and everything happening on that is automatically forwarded to the clients. So, it's sort of: As soon as you connect, you subscribe to everything. The actual subscriptions I then handle by filtering this stream of incoming events by all subscriptions. But I know this will probably be different for other protocols (like Cesar's S7 Events) So, in general, I would agree with your assumption, but in this case, I would try to use one connection for as much as possible. Assuming a S7-1200 is used and it has an HMI and the company has some sort of control-system. Then already 2 of the 3 available connections are used. In case of KNX: You usually need to keep one connection free for the engineering software, one for us and usually if you need any form of bridge or converter that also consumes at least one connection. Chris -----Original Message----- From: Niclas Hedhman <[email protected]> Sent: Freitag, 21. Januar 2022 09:43 To: [email protected] Subject: Re: More possible problems with connection pools On 2022-01-21 09:19, Christofer Dutz wrote: > So instead of having the subscriber having to keep the connection to > keep the subscription alive, I would opt for adding subscriptions to > the connection and keeping them valid, even after the connection is > returned to the pool. Yes, this causes subscriptions from multiple > places in your application to get mixed up and potentially one part > could interfere with another one (Like unsubscribe a subscription a > different part subscribed for). But I think from an API perspective > this would probably be the best option for the normal use-cases. I have had this exact issue (well, not KNX) a long time ago and I would like to provide a recommendation; * Don't put subscription on Request/Reply connections. it will down the line complicate matters, with re-subscriptions when a request/reply fail for small modest reasons, the connection is torn down, and the subscriptions needing to be re-established, and possible clients unsubscribing while that is going on. AND dynamic allocation of connections becomes harder too, as one has to move subscriptions from one connection to another to be able to delete a connection from the pool. Try to put subscription in separate API/interface. Cheers Niclas
