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
