Hi Sebastian, Yeah ... like your name more :-)
And I’ve sort of dug a bit more ... and currently we have the “PlcConnection” which contains the TagBuilder, PlcValueBuilder, the read, write, subscribe stuff ... I think we don’t even want to proxy these ... the interesting part might be the Protocol ... as this seems to be the thing that is associated with the individual connections. In ADS the Protocol for the UDP Config stuff is different from the ADS TCP stuff ... in PROFINET the raw subscription stuff is separate from the Read/Write/Config .... So possibly even worth thinking of a Multi-Protocol or AggregatedProtocol ... Chris Von: Sebastian Rühl <[email protected]> Datum: Mittwoch, 10. Mai 2023 um 13:34 An: [email protected] <[email protected]> Betreff: Re: AW: [DISCUSS] Have some sort of multi-connection? Hi Chris, I also had the name AggregatedConnection flying around in my head (maybe I think to much of multi vitamin when reading MultiConnection :D) What would be helpful is to list the scenarios in a wiki site and then think through what each connection would have to to in which usecases. This might help to better find edge cases and surprises. Also approaching that with TDD might be super helpful to get a better feeling for your proposed design. - Sebastian On 2023/05/10 09:27:15 Christofer Dutz wrote: > Hi all, > > I’ve been thinking about this for the last few days now and I think I’ve got > an idea: > > > * We add some sort of “MultiConnection” ... it has the same general > interface as our other connections do > * Internally the MultiConnection has named-connections which are stored > in a map > * When connecting, we somehow need to be able to pass in these multiple > connections > * All Disconnect/Connect etc. functions simply relay to all named > connections > * Additionally the MultiConnection has a “getConnectionNames” and a > “getConnection(name)” method > * The integration testsuite gets extended to you can pass in an optional > connection name which it then uses to select the right internal connection > > One thing I’m not quite sure about how to handle it ... we currently have the > idea of a driver being able to provide a default transport. This can be > overridden by the user. Like in modbus-rcp, which defaults to serial, but you > can switch it to TCP. > > This mechanism will be difficult with MultiConnection. > > We could mark one connection as “default connection” and this one keeps the > felxibility we had, but the others would be fixed. > Or we simply not allow this flexibility for MultiConnection connections. > > I think now allowing the overrides would be the simpler solution and for all > the drivers I know that need multiple connections, you can’t really run them > with anything different anyway. > > So, what do you folks think? > > So I would opt for doing the MultiConnection thing as described (not fixed on > the name though) and simply not allowing transport overrides for > multi-connection drivers (We could always add that feature later, if we find > out to require it) > > Chris > > Von: Ben Hutcheson <[email protected]> > Datum: Samstag, 6. Mai 2023 um 19:39 > An: [email protected] <[email protected]> > Betreff: Re: [DISCUSS] Have some sort of multi-connection? > Hi, > > Definitely +1, it would be great to be able to have multiple > connections/protocols handled in a consistent way. PROFINET is a prime > example of one that would benefit, as it uses multiple protocols (LLDP, > DCP, PNIO) as well as multiple end devices. > > Let me know if I can help. > > Ben > > On Sat, May 6, 2023 at 1:20 PM Lukas Ott <[email protected]> wrote: > > > +1 for building a more generic solution for multi-connections as it helps > > for PROFINET and ADS as well > > > > Am Fr., 5. Mai 2023 um 15:17 Uhr schrieb Christofer Dutz < > > [email protected]>: > > > > > 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 > > > > > >
