Well I think the Connection Pool doesn’t quite match in this case. It’s more of a fixed group of connections, where each serves a different purpose. And they share the metadata and functionality ... so for example if one connection detects that the S7 is a 300 or 400, then the driver supports subscriptions and the main connection is used to setup the subscription on the second subscription connection.
Chris Von: Jinlin Hong <[email protected]> Datum: Donnerstag, 11. Mai 2023 um 03:07 An: [email protected] <[email protected]> Betreff: Re: AW: [DISCUSS] Have some sort of multi-connection? Hello Chris. Now that we have PlcConnection, is MultiConnection or AggregatedConnection something like a connection pool to store PlcConnection? Jinlin Christofer Dutz <[email protected]> 於 2023年5月10日 週三 下午8:13寫道： > 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 > > > > > > > > > >
