[DISCUSS] What should the "Connection Pool" be named?

[Christofer Dutz <ch...@c-ware.de>]

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.

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

RE: [DISCUSS] What should the "Connection Pool" be named?

[Christofer Dutz <ch...@c-ware.de>]

Well in go that's sort of how I currently do things:

The ConnectionPool/Cache hands out PlcConnectionLeases ... these have the same interface as a PlcConnection, but are only a proxy to a real connection ... you can use it as every other connection, as soon as you call close, it's given back to the Pool/Cache and the connection in the lease is removed. If you then continue to use the connection, you get errors/panics/Exceptions.

I think we should do it like in JDBC or normal database connection pools ... so grab a connection, do something atomically with it and give it back as soon as you're done with it. 

Now managing concurrency on a universal connection level is unmanageable, I think ... cause, this would need to know for each protocol, which operations are an Atomic unit.

Chris


-----Original Message-----
From: Niclas Hedhman <ni...@hedhman.org> 
Sent: Freitag, 21. Januar 2022 17:53
To: dev@plc4x.apache.org
Subject: Re: [DISCUSS] What should the "Connection Pool" be named?


Here is how I would create the abstraction; There are "physical connections" from the PLC4X to zero, one or more devices, and a single connection is held to each device. Then we need a solution where different threads can access each such physical connection in an ordered/shared manner. So, the client API hands over a "virtual connection" which knows how to coordinate with the virtual connection (and that implementation is hidden from API, and can change over time, and completely different for different drivers, and possibly even configurable for different device types).

The "Virtual driver" is very very light, and no pool is needed. No cache is needed. Straight up "request a connection, hold on to it for as long or as short as you want, then release it".


Cheers
Niclas



On 2022-01-21 12:35, 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.
> 
> 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

Re: [DISCUSS] What should the "Connection Pool" be named?

[Niclas Hedhman <ni...@hedhman.org>]

Here is how I would create the abstraction;
There are "physical connections" from the PLC4X to zero, one or more 
devices, and a single connection is held to each device. Then we need a 
solution where different threads can access each such physical 
connection in an ordered/shared manner. So, the client API hands over a 
"virtual connection" which knows how to coordinate with the virtual 
connection (and that implementation is hidden from API, and can change 
over time, and completely different for different drivers, and possibly 
even configurable for different device types).

The "Virtual driver" is very very light, and no pool is needed. No cache 
is needed. Straight up "request a connection, hold on to it for as long 
or as short as you want, then release it".


Cheers
Niclas



On 2022-01-21 12:35, 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.
> 
> 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

RE: [DISCUSS] What should the "Connection Pool" be named?

[Christofer Dutz <ch...@c-ware.de>]

Hi Stephen,

Regarding the name ... we could Name it Cache (which is technically more correct) but we add in the JavaDoc that it's sort of a special ConnectionPool and perhaps add a page to the website which also mentions that, so someone coding with google, can find it. I'm happy with that.

well admittedly we spaced out the "programming" part in PLC4X till now (unless you can do that via normal write operations (Which I sincerely hope no device allows). My first reason to not allow this, was that I knew how unsecured these boxes are and I didn't want to have script kiddies write stuff for ruining hardware. The other is that this is where I have seen things go down proprietary road everywhere. So, we would probably need to support programming for all different automation systems, which I wasn't planning on implementing. 

So, consider PLC4X a pure data reading/writing tool.  Who knows? Mabe one day the industry wakes up and funds projects like this and we'll add a "Programming API" which would be cool for some "Continuous-Delivery"-like features. Or someone wants to implement this ... but I guess till then, I'll not touch that ;-)

But geeee ... hopping from USB to serial to network sounds pretty complicated, but I understand why this might be supported.
I think for stuff like this we'll really have to play with the transports and extend the driver contexts to support that. But I think we generally need to do this more. The S7 driver currently tries to identify the remote device, based on its serial number. It also currently stores this in the context. So in general the driver could access this information and react differently. 

For example the S7 driver could return in the MetaData that it supports subscriptions, if the device is a S7 400 or one of the devices Cesar is working with, but say that it doesn't if it's one of my little 1200 or even a LOGO. Same with the "long" types like "LINT", "LUINT" and "LREAL", which not all types support, we could then switch to byte-based access in this case. But that's fine-tuning we would need to add over time, I think. But the same could be done for different transport variants.

Chris


-----Original Message-----
From: Stephen Snow <s4...@gmail.com> 
Sent: Freitag, 21. Januar 2022 13:55
To: dev@plc4x.apache.org
Subject: Re: [DISCUSS] What should the "Connection Pool" be named?

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.

Re: [DISCUSS] What should the "Connection Pool" be named?

[Stephen Snow <s4...@gmail.com>]

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.