Hi Lukasz, Answers below inline
> At present we do not offer end user an API to react on connection > shutdown or failure. There is no way for him to find that ie. link died > and his program needs to take action. Sounds like we should add a EventListener so you could register for events and get called back. > > What I currently also do not understand/lack clearance is how stack > configurer interacts with TCP connection. Here what bothers me: > - Is there a new stack/decode instance per each active connection? > - What is was intended design for driver context and why it is > inaccessible via PLC connection interface? > > I suppose that stack per connection is desired case, but if that's true > why we pass classes and instead of creating instances in stack configurer? We could add additional methods which accepts a lambda expression which in turn gets the configuration as parameter. This way you have the choice how you want to use it. (Keep in mind that the StackConfigurer is an opinionated api and there is no requirement to use it at any cost) > My case here is intended to attach connection state listener but also an > message listeners which could help debugging message exchanges. All > without tapping into wire. In general I think it would be helpful to tap into several places e.g.: Just before the conversion to the protocol specific types Just before sending the build protocol specific types onto the wire > > A default way we advertise is making PCAP recordings > which is fine for development. What I look for is an "logging" interface > to be used in production or test environments without necessity to get > libpcap involved. This would allow creation of additional tools if needed. Also this could be seen as an audit log 👍 > > Best, > Łukasz Sebastian
