EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  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: CAS server and partial vectors
From: "Jeff Hill" <[email protected]>
To: <[email protected]>, <[email protected]>
Date: Tue, 21 Apr 2009 09:51:58 -0600
> Ok but how does it knows how many elements to ask for. 

The client can call ca_element_count() to determine the number of elements
in the array. The service provides this number when the channel connects.
Admittedly, that will not tell them what the service is currently providing
with a particular response.

> Thinking about it the risky part would be to have a 
> new server sending partial data and a old client 
> expecting a zero padded payload.

We can all agree that we need to provide no more than requested when it?s a
get request - which writes directly into a user's buffer.

For the get callback request and the subscription request the discussion is
more complicated. At one time I was worried that supplying a different
(smaller) current number of elements in the callback would cause bugs in
client code because authors might neglect to check the element count
argument supplied to them in the callback. But, admittedly, from where we
are standing today this might be viewed as pandering to fears, and that this
type of bugs are easily fixed in the client code.

In the future we probably should have two behaviors:

Behavior 1: 
We need to get to a situation where the user could ask for any slice out of
a multi-dimensional array (currently slices always start at zero and we
don?t support multi-dimensional arrays). If that type of request can't be
satisfied because the slice is out of bounds then it's probably best for it
to fail. I believe that zero padding isn?t an ideal response behavior in
this context, and in the future it should be phased out. However, a change
in behavior like that probably should not occur in a point release (in a
bug-fix release).

Behavior 2:
Alternatively, the client side tool could specify no bounds when making the
request, and then he might receive the entire extent of the array whatever
its bounds currently are, if he is making a get callback or a subscribe
request. To be clear however, it does not currently work like that. One
possible fix in the future (workable in the legacy client side api) would be
to trigger this behavior when the client specifies an element count of zero.

Jeff

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Bruno Coudoin
> Sent: Saturday, April 18, 2009 3:06 AM
> To: [email protected]
> Subject: RE: CAS server and partial vectors
> 
> Le vendredi 17 avril 2009 à 18:47 -0600, Jeff Hill a écrit :
> > Hello Bruno,
> >
> > Currently, it works like this.
> >
> > - the client can ask for no more than the number of elements provided by
> the
> > service when the channel connects to the PV.
> 
> Ok but how does it knows how many elements to ask for. As I see it, only
> the server can know the current number of element in its gdd.
> 
> > - the client always gets the number of elements he requests,
> 
> This is ok for me but in my case I will always ask for the max number of
> elements. If I don't do this I would just loose data.
> 
> >  and should the
> > service provides less, then the server zero pads in the protocol.
> 
> Ok, that's what i saw.
> 
> > I will admit that one could make a good case for this not being terribly
> > flexible, but this was a behavior adopted a long time ago and we are
> careful
> > to preserve backwards compatibility.
> 
> I understand but there is probably a way to fix it and keep backward
> compatibility. One can assume that if nobody complains about this is
> because no one use epics to send partial vectors.
> 
> Thinking about it the risky part would be to have a new server sending
> partial data and a old client expecting a zero padded payload.
> 
> By the way I don't know the epics ecosystem enough to make a proposal.
> 
> > One solution might be to make the first element specify the number of
> > elements that follow. That would, admittedly, not help with bandwidth
> > consumption.
> 
> Yes, at least this would fix the functionality issue.




Replies:
RE: CAS server and partial vectors Bruno Coudoin
References:
CAS server and partial vectors Bruno Coudoin
RE: CAS server and partial vectors Bruno Coudoin

Navigate by Date:
Prev: 答复: Problems using the sscan record 张招红
Next: davis weather monitor II with Linux ioc Patrick Thomas
Index: 1994  1995  1996  1997  1998  1999  2000  2001  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: CAS server and partial vectors Bruno Coudoin
Next: RE: CAS server and partial vectors Bruno Coudoin
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·