Hello, On Fri, 2022-01-21 at 11:35 +0000, Christofer Dutz wrote: > Hi all, > > in the past we had a "ConnectionPool" ... but in reality, we don't > have a pool of multiple connection to one target, like in databases, > but usually we have only one connection to each source in the "pool". > But we can have multiple connections to multiple targets. > > I guess that's why Julian named the new version of the Pool > "Connection Cache". This sort of comes closer to what it technically > is. > I don't mind use of either name, personally, but if you have a good reason for naming it a cache, that should be documented and explained why (we) feel it is more suitable. This should cover some implementation details too I would think. > So now the question is: How should we generally name this thing? > > I would opt to stick with ConnectionPool despite it being more a > ConnectionCache. The reason for this is that people looking for > something with the functionality, will probably start looking for a > ConnectionPool and not a ConnetionCache. I think the inside nature of > the component is more a context-detail and we should rather provide > people with what they intuitively would look for. > > But I would like to hear your thoughts on this. > > Chris To put another wrinkle in this conversation. PLC's and HMI products that hang on Industrial networks such as all of these wonderful ones we are talking about, but let's take EIP. I am going to cite an example of my work day. Customer calls, says "Hey Stephen, can you come over and look at my FilberFlanger, it's not meshing my grapple grommets?" I say "Sure, be right over." Pack up my PC and interface goodies to go see what's the matter. I want to connect to the PLC and watch the process while connected, live debugging. But the main panel housing the PLC actually is inside of the Machine guarding and unreachable without special safety interlock defeating. However, there is a connected HMI on a serial network I can connect to with USB on it's programming port. So my programming software for the PLC is now connected through a network bridge in the device (HMI panel) from my USB eventually to the EIP network the PLC is on. This is termed "jumping" by Rockwell, and most PLC's and HMI products they sell will accomodate it. They (Rockwell, and others I noticed) will usually only offer this through the use of a more advanced driver, normally referred to as "enterprise" or some such. Which finally brings me to my point on drivers, there may need to be different types considered, as in their expected capabilities. So a direct connect driver should be the simplest IMO, usable in most IIOT use cases where you are making a device to "hang off" a PLC EIP or other open network, like a "smart IO sensor", etc... even for a lot of the PC based uses. For multiple connections and larger networked application building it would likely be more appropriate to look at a server role for the driver. The Rockwell micro plc I am playing with now can handle up to 16 simultanious connections on TCP/UDP with either Modbus and EIP for example, and it is just a small guy. But it will only allow one port ownership (which ownership is meant for the programming role).
Regards, Stephen P.S. if you need some testing for pooled connections to a PLC on a Modbus or EIP network I can help.
