Re: GW status

[Ralph Lange <Ralph.Lange@bessy.de>]

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