Hi all, So, I quickly went through our Java stuff and wrote down an initial version: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=255069989 Please review it, update and correct it where needed.
So far I see ADS, Profinet and S7 in need of some solution. Chris Von: Ben Hutcheson <[email protected]> Datum: Donnerstag, 11. Mai 2023 um 04:11 An: [email protected] <[email protected]> Betreff: Re: AW: [DISCUSS] Have some sort of multi-connection? Hey, It sounds like a plausible way of doing things. I like Sebastian's idea of exploring all the use cases that we have. One thing I'm not 100% sure about is when we have multiple devices on the network and we need to share a connection between them all. For Profinet we have shared LLDP, UDP and PNIO Endpoints on the controller, which all devices use. Ben On Thu, May 11, 2023 at 3:08 AM Jinlin Hong <[email protected]> wrote: > 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 > > > > > > > > > > > > > > >
