Re: Receiving duplicate monitor values using CA PV Gateway

[Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>]

I wasn't even aware of that thread ... nice one! (And I did have other things to do during that week.)

That extra update is related to the function principles of Channel Access and the Gateway. (It also depends on other clients being connected to the same PV through the Gateway, actually.)

The usual order of things when a client establishes a monitor:

1. Monitor request - 2. Current value returned by the IOC immediately - 3.-n. Updates sent by the IOC.

The original Gateway mode was with active cache, so that an external client:

1. Monitor request - 2. Gateway returns cached value immediately - 3.-n. Updates sent by the IOC are forwarded.

The problem: when doing a plain get(), the external client would often see a different value through the Gateway (the value of the last monitor update sent by the IOC) compared to connecting to the IOC directly (the real current value which might differ - e.g. less than the deadband for an analog value).

The '-no_cache' option was added so that externat get() requests would *always* be repeated internally to the IOC. More traffic to the IOC traded in for more transparent behavior on the outside.

Now, in that -no_cache mode, when a monitor connection to the PV exists and an additional external client connects - what should the Gateway do?

It doesn't have the cached value, so it must do another get() on the inside to the IOC. When the answer to that get() arrives, it can't be distinguished from a monitor update. So with a list of clients for that PV, which ones should get the update, which shouldn't?

Also, there are four "event" (reason) bits that can be combined when subscribing. The CA value update from the IOC, however, does not contain information about the reason why this particular update has been sent. Tough for a Gateway that tries to combine multiple external client subscriptions into a single one to the IOC.

These things, especially in situations with multiple external clients connecting quasi simultaneously, make it pretty hard to come up with a simple logic that doesn't lose updates in non-standard situations.

I remember that after trying for quite a while, I eventually was talking myself into being happy with a situation that would send double updates in specific situations. It's relatively easy to filter-out a double update, and relatively hard to fabricate a missing one.

But - by all means: if you feel inclined to give it a try, please go ahead. The current behavior is far from perfect, no doubt. I am not actively maintaining the Gateway, but explaining things and reluctantly looking at pull requests for sure.

Cheers,
~Ralph