From: Marty K. <mrk...@co...> - 2010-01-22 13:04:26
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> sheng peng wrote: <blockquote cite="mid:182...@we..." type="cite"> <style type="text/css"><!-- DIV {margin:0px;} --></style> <div style="font-family: times new roman,new york,times,serif; font-size: 10pt;"> <div>Hi Marty,<br> A few questions:<br> <br> 1. If queueSize == 0, you mentioned only onPut makes sense.<br> So the difference is calculated by CA server. If CA sever has no data copy, then no way to calculate, right?<br> <br> </div> </div> </blockquote> <br> Correct.<br> <blockquote cite="mid:182...@we..." type="cite"> <div style="font-family: times new roman,new york,times,serif; font-size: 10pt;"> <div>Gateway definitely make this much more complicated:<br> 1. I don't know if onRateLimit is really useful to client. <br> Client has no idea how often data could change. By rate limit, client could get some fast update for ripples, then misses major chang<br> </div> </div> </blockquote> Perhaps what I mean is<br> <br> onPeriodic<br> <br> which means send a monitor every x seconds. If no change do not send.<br> This does seem useful and over the years this has been mentioned as a desirable feature<br> <blockquote cite="mid:182...@we..." type="cite"> <div style="font-family: times new roman,new york,times,serif; font-size: 10pt;"> <div>2. monitor plug-in interface should be clearly defined. <br> </div> </div> </blockquote> <br> It is defined in pvData and CAJv4. The key features are:<br> <br> 1) PVA (PVData Access). passes a "PVStructure pvOption". This structure must be understood by client and the server plugin. The client side of PVA has no knowledge of internals of pvOption. The monitor code (implemented by pvData) does require that pvOption has a field giving the name of the monitor algorithm. <br> <br> 2) At initialization each monitor plugin must register itself to the monitor system.<br> <br> Thus PVA itself has no knowledge of how monitors are generated.<br> <blockquote cite="mid:182...@we..." type="cite"> <div style="font-family: times new roman,new york,times,serif; font-size: 10pt;"> <div> I think the deadband you mentioned could be extended to just "reasons of posting monitor" and mapped to a bitset MASK.<br> <br> </div> </div> </blockquote> <br> Yes and mask explaining what caused monitor will be send back to client. Sorry if I did not make myself clear.<br> <blockquote cite="mid:182...@we..." type="cite"> <div style="font-family: times new roman,new york,times,serif; font-size: 10pt;"> <div>3. When gateway creates monitor as shared. It essential maintains a full copy of the original pvData. So the noisy channel is still trouble.<br> </div> </div> </blockquote> <br> Note that I said that, not like current implementation, shared should only apply to arrays. And for arrays a put will always mean change so that expensive array comparisons are not required.<br> <blockquote cite="mid:182...@we..." type="cite"> <div style="font-family: times new roman,new york,times,serif; font-size: 10pt;"> <div> Should gateway set the deadband of the original pvData to the minimum value of the deadband his clients asks? I guess so.<br> </div> </div> </blockquote> <br> Hmm!<br> <br> Will we let a client specify and get a deadband that is less than the deadband stored in the record?<br> <br> If so the gateway would have to ask for a deadband of 0 or at least the smallest of any client request.<br> <br> We could just say that, when the client specifies a deadband less than the record's deadband, the record's deadband will be used.<br> <br> I would vote for this. <br> <blockquote cite="mid:182...@we..." type="cite"> <div style="font-family: times new roman,new york,times,serif; font-size: 10pt;"> <div> Do we need a minPercentage to handle the onPercentChange?<br> </div> </div> </blockquote> <br> I think yes.<br> <br> Thus perhaps<br> <br> deadband<br> monitor<br> archive<br> Should be changed to<br> deadband<br> monitor<br> absolute<br> percent<br> archive<br> absolute<br> percent<br> <blockquote cite="mid:182...@we..." type="cite"> <div style="font-family: times new roman,new york,times,serif; font-size: 10pt;"> <div><br> 3. How to make gateway as transparent as possible is still an issue. <br> For certain reasons of monitors, it is easy that gateway just post monitor to the clients who's monitor mask has matched bit with reason of update.<br> But for the update of numeric data, even gateway gets monitor with the smallest deadband its clients requested, it still has to keep the deadband of each client in mind.<br> </div> </div> </blockquote> <br> Not if we use rule above. Gateway just sets deadband to 0. PVA will take care of clients connected to the gateway.<br> <blockquote cite="mid:182...@we..." type="cite"> <div style="font-family: times new roman,new york,times,serif; font-size: 10pt;"> <div> For predefined onAbsoluteChange or onPercentChange, it is ok. For user defined numeric based monitor, gateway has to understand how to calculate difference >= deadband.<br> So it needs to have plug-in as well, right?<br> <br> </div> </div> </blockquote> No it does not. The actual server sends monitors to the gateway. The gateway has a PVRecord (no javaIOC support; just data), that mirrors the actual record. When it does the put, the PVField implementation calls postPut. The PVA server takes care of sending monitors to the clients of the server.<br> <br> Note that the gateway calls factories implemented by pvData to create the PVRecords. Thus it does NOT have to implement anything for PVRecord.<br> <br> It does have to implement the equivalent of org.epics.ca.server.imp.local and probable what is in org.epics.pvData.monitor.<br> For both it just passes requests to that actual server.<br> <br> Marty<br> <blockquote cite="mid:182...@we..." type="cite"> <div style="font-family: times new roman,new york,times,serif; font-size: 10pt;"> <div>Regards<br> Sheng<br> </div> <div style="font-family: times new roman,new york,times,serif; font-size: 10pt;"><br> <div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"> <hr size="1"><b><span style="font-weight: bold;">From:</span></b> Marty Kraimer <a class="moz-txt-link-rfc2396E" href="mailto:mrk...@co..."><mrk...@co...></a><br> <b><span style="font-weight: bold;">To:</span></b> <a class="moz-txt-link-abbreviated" href="mailto:epi...@li...">epi...@li...</a><br> <b><span style="font-weight: bold;">Sent:</span></b> Thu, January 21, 2010 5:04:30 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: Subscription ("Event") Type Implementation<br> </font><br> Ralph said:<br> <br> > As discussed last week, I don't like a design where a Gateway has to <br> > separately implement every plugin that the servers use. The IOC plugin <br> > might be written in a different language, or use external facilities <br> > that the Gateway doesn't know about (e.g. timing system).<br> ><br> > I would much prefer a design where the server provides a bit in a bit <br> > field for each subscription type (server specifies the bit at <br> > subscription time) that it sets in the update message, so that a Gateway <br> > could just forward updates to the clients with a matching bit set, <br> > without having to reimplement any plugin functionality.<br> > <br> See below for how this may be part of the solution.<br> <br> I have been thinking more about monitors and how a pvData Gateway would <br> implement them. Forget almost everything I said in previous messages.<br> <br> Let me review the basics of how monitors are implemented.<br> <br> PVField, the data interface attached to every field, has a method<br> <br> void postPut();<br> <br> The rule is that the code that implements any PVXXX that extends <br> PVField and has a put method must call postPut when put is called. Then <br> PVField takes care of what to do. NO OTHER code calls postPut. This NO <br> normal support code calls postPut.<br> <br> The monitor implementation allows a client to monitor an arbitrary <br> subset of the fields in a PVRecord. For an example I will use a power <br> supply record so that we have something more than just a V3 style <br> record, i.e. the example has a structured rather than a flat record <br> structure. This the record has<br> <br> powerSupply<br> timeStamp<br> alarm<br> power<br> value<br> alarm<br> display<br> ... other fields that are implementation specific<br> voltage<br> value<br> alarm<br> display<br> ... other fields that are implementation specific<br> current<br> value<br> alarm<br> display<br> ... other fields that are implementation specific<br> <br> <br> <br> A client could ask to get a structure that has<br> <br> clientSpecific<br> alarm<br> value --- data from power.value<br> display -- data from power.value<br> <br> Two other important points: 1) when CAJv4 sends a monitor ONLY the <br> changed fields are sent. 2) It is possible to group puts to multiple <br> fields in a single monitor packet.<br> <br> Given this what should the gateway do when the first client connects to <br> a channel?<br> <br> I think the following:<br> <br> Connect to the real channel.<br> <br> Monitor the entire real PVRecord.<br> <br> Then it always has an up to date copy of the data.<br> <br> Two big issues:<br> <br> 1) What monitor options should it request?<br> 2) What about noisy channels? In other words what about what MDEL and <br> ADEL do for epics V3?<br> <br> Let me discuss the first question and then the second.<br> <br> <br> Monitor algorithms are extensible and each algorithm is registered <br> during initialization. Currently the following are implemented:<br> <br> onPut - a put to any of the monitored fields causes a monitor.<br> onChange - A change to any of the monitored fields causes a monitor. <br> This is expensive for big arrays since a comparison is made.<br> onAbsoluteChange - A scalar numeric field named value must be one of the <br> monitored fields. The client specifies the delta.<br> onPercentageChange - A scalar numeric field named value must be one of <br> the monitored fields. The client specifies the delta which is now a <br> percentage.<br> <br> In addition the client can specify the queueSize<br> <br> -1 means just send a notification but no data<br> 0 no queue and in server do not create a copy of the data. Just copy the <br> actual data. Only onPut makes sense.<br> Also every field the client requested is sent every time because <br> there is no copy to compare with the new data.<br> 1 no queue but only one copy in the server.<br> >1 this is the queue size.<br> <br> Given these I would say the the gateway would ask for onChange with a <br> queueSize of 1.<br> <br> Pros:<br> <br> 1) gateway will always have latest data.<br> 2) CAJv4 will handle everything for gateway clients.<br> <br> Cons:<br> <br> 1) Noisy channels will cause excessive monitors being sent to the gateway.<br> 2) Gateway can not properly implement onPut<br> <br> <br> Now let me mention how MDEL and ADEL might be handled for structured pvData.<br> <br> Since multiple value fields can appear in a PVRecord a single MDEL and <br> ADEL will not work. In addition they only make sense for a numeric <br> scalar field. For such fields we could have an attached structure as <br> follows:<br> <br> value<br> deadband<br> monitor<br> archive<br> <br> Then the database developer can optionally define a deadband structure <br> for any numeric scalar field. The monitor implementation on the server <br> will look for the deadband and use if it finds it.<br> <br> Now let me propose changes to what monitor provides:<br> <br> Get rid of onPut completely.<br> onChange is supported but deadband decides if monitors are raised. If <br> data is an array then any put is a change<br> onAbsoluteChange, onPercentageChange still use deadband but also keeps <br> an extra deadband for the client<br> <br> monitorCreate has two new arguments<br> <br> int mask<br> booleam shareData<br> <br> And initially definitions for mask bits are<br> <br> monitorDeadBand 0x01<br> archiveDeadBand 0x02<br> <br> Note that createGet, etc already have the shareData argument. The <br> meaning should be changed to shareArrayData because that is why share <br> was invented. For scalar data always make a copy.<br> <br> <br> One additional monitor algorithm is supported<br> <br> onRateLimited<br> <br> This specifies a maximum number of monitors per second, e.g. send no <br> more than once every second<br> <br> Now for queueSize<br> <br> -1) This means notify only. Lets get rid of this. It is easily <br> implemented other ways.<br> 0) This means share data. With share as an argument it is no longer needed.<br> 1) means single copy<br> >1) This is queueSize.<br> <br> With these changes the gateway can issue a monitor request for <br> onChange, shareData=true, mask = monitorDeadBand | archiveDeadBand<br> <br> This will handle most client monitor requests.<br> <br> If gateway receives a createMonitor request with a mask that has other <br> bits set, I think it will have to issue an additional monitor request.<br> <br> Comments?<br> <br> Marty<br> <br> <br> <br> <br> <br> <br> ------------------------------------------------------------------------------<br> Throughout its 18-year history, RSA Conference consistently attracts the<br> world's best and brightest in the field, creating opportunities for Conference<br> attendees to learn about information security's most important issues through<br> interactions with peers, luminaries and emerging and established companies.<br> <span><a moz-do-not-send="true" target="_blank" href="http://p.sf.net/sfu/rsaconf-dev2dev">http://p.sf.net/sfu/rsaconf-dev2dev</a></span><br> </div> </div> <!-- cg17.c2.mail.ac4.yahoo.com compressed/chunked Thu Jan 21 21:15:56 PST 2010 --> </div> </blockquote> <br> </body> </html> |