EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: GW status
From: "Ernest L. Williams Jr." <[email protected]>
To: Ralph Lange <[email protected]>
Cc: "'Amedeo Perazzo'" <[email protected]>, "'Core-Talk'" <[email protected]>, "'Dirk Zimoch'" <[email protected]>, "Ernest L. Williams Jr." <[email protected]>, Stephen Lewis <[email protected]>
Date: Wed, 05 Aug 2009 08:06:01 -0700
Ralph Lange wrote:
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.
Ralph do you agree that with respect to TCP-circuit load the IOC does get shielded? So, yes the IOCs will get hit with search requests (UDP, BCAST) but this is as you say a trade-off. Also, statistically most connections to PVs are monitored as opposed to cagets.



Thanks,
Ernest





Cheers,
Ralph



Replies:
Re: GW status Ralph Lange
References:
RE: GW status Jeff Hill
Re: GW status Stephen Lewis
Re: GW status Ralph Lange

Navigate by Date:
Prev: Re: GW status Ralph Lange
Next: Re: GW status Ralph Lange
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: GW status Ralph Lange
Next: Re: GW status Ralph Lange
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·