Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Wed, 05 Aug 2009 09:03:34 -0400

Hi Steve,

Stephen Lewis wrote:

I consider forwarding a ca_put from a client into a ca_put-notify a

design flaw: behavior would be very different between a local IOC on

the client LAN and a distant IOC behind a gateway.

Correct.

Keep in mind, though, that until Jeff's very recent patch to PCAS the GW

simply couldn't distinguish between a client doing a ca_put and a client

doing a ca_put_notify.

In that situation, forwarding a simple ca_put as an acknowledged

ca_put_notify is definitely better than forwarding a ca_put_notify as a

fire-and-forget ca_put, faking the acknowledgment. So, from the two

possible options which were both wrong, the gateway was using the better.

Caching/no-caching:

Among the GW's objectives are keeping load off the IOCs and acting

transparently. With certain aspects of Channel Access, e.g. answering

get requests, forwarding IOC-side beacons to the clients, and forwarding

client side name-resolution-requests to the IOCs, these two objectives

are contrary. If the GW acts 100% transparent, it does not offload the

IOCs (in some cases, it would even put more load onto the IOCs). If the

GW tries to shield the IOCs, it will not be able to act completely

transparent. While the original approach was trying to implement a

reasonable compromise, the direction that Dirk is pursuing is certainly

the right one: when the level of compromise is made configurable for

these aspects, the user can select the appropriate behavior for each GW

instance.

Cheers,
Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System