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.
