We do have SingleProtocolStackConfigurer which suggests that somewhere
in the past there was an intent to have a
"MultiProtocolStackConfigurer". ;-)
Since we are reaching that point it raises a question what is the role
of PlcConnection and how to coordinate it, in case if it covers multiple
streams.
As far I remember one of protocols where we struggled with TCP and UDP
was Ethernet/IP which uses first for setup and other for subscriptions.
I believe that with work you are starting we will be able to get closer
to EIP spec.
One important point is - whether we isolate netty completely from the
game, and make protocol stack configurer a more independent thing or we
keep pushing everything over netty. We have a number of troubles caused
by netty - timeouts (with pending PR), we laso used to have connection
and thread leaks. Netty, with all its optimizations, is fairly
complicated underneath. Sometimes I feel we don't even get it. Its use
also seems to be a bit historic, cause first drivers which got
implemented by hand uses netty codecs.
Since our current way of setting up connection feels quite complicated,
I fear that we will make it even harder to debug over time. Now we pack
i.e. ether or canbus frames into a byte buffer just to spin netty's
old-io loop which fires our handler which with decoding logic.
Best,
Łukasz
On 5.05.2023 15:17, Christofer Dutz wrote:
Hi all,
while going through Cesar’s changes I noticed that he actually addressed
something I keept on avoiding ;-) ... Multi-Connections. I know I needed them
for PROFINET (Raw base transport and UDP config) as well as ADS (TCP base
transport and UDP config) ... I solved the problem by implementing the UDP
stuff manually, completely avoiding Netty .. but I think it would be more in
the spirit of PLC4X to do it in a cleaner way ... as Cesar did it.
However, Cesars version is hard-coded for S7 and S7HA. I would suggest to build
a more generic solution ... what do you folks think?
Chris
