Menu
▾
▴
RE: Provider-provider
|
From: <dav...@di...> - 2012-05-03 10:32:00
|
Of course instead the simple provider resolution can be thought of as a special case of the serial provider resolution from a list of providers with the list consisting a single provider. In which case we have: a) Specify a list of 1 or more providers and try to connect to each in turn. b) Broadcast over UDP to find a match. c) Use a directory service. d) Other (extensible by user) There's not much in it, but the former view (serial resolution of a list of providers is a composite of simple) is I guess more general. Either way the serial provider resolution from registered providers is also derived from the serial provider resolution from a list where the list consists of the registered providers. Dave. -- Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom -----Original Message----- From: dav...@di... [mailto:dav...@di...] Sent: 03 May 2012 10:55 To: Ral...@gm...; epi...@li... Subject: RE: Provider-provider The serial provider resolution can be thought of as being made up by composition from the simplest type of provider resolution in the draft proposal, where you just specify the provider, a bit like a composite data pattern. In which case the set of methods for provider resolution might be: a) Specify the provider. b) Broadcast over UDP to find a match. c) Use a directory service. d) Other (extensible by user) e) Composites of the above. Dave. -- Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom -----Original Message----- From: Ralph Lange [mailto:Ral...@gm...] Sent: 02 May 2012 13:40 To: EPICS V4 Developers Subject: Re: Provider-provider On 02.05.2012 12:25, White, Greg wrote: > [adding epics-pvdata-devel] > > Hi Ralph, could you describe your proposal more completely for me? I > couldn't get it from the ASCII art. I think it got messed up through > the mail system. I put some specific questions inline. My second mail was shortening the lines to avoid being messed up. > On 25 Apr 2012, at 18:50, Ralph Lange wrote: > >> Marty, >> >> the more I think about the plug-in approach, the more I like it. >> >> There should be one default provider that is used when the app does >> not specify one. Could be the first provider to completely avoid env var config. >> >> All we have to do is write three generic provider policy blocks: >> >> 1. Serial name resolution >> Queries all providers that registered with it in series, i.e. asking >> the next one when one timed out. Returns the first that answers. > What does the querying? Do you mean "When a client agent of pvAccess > is asked to get the value of a PV it has not been asked the value of > before, it then queries a series of client side plugins of pvAccess > for the provider that should be used for that new PV? The client agent then uses the provider name value "V4" or "V3" > corresponding to the first plugin to answer positively that it knowns > the correct provider for the given PV." When the app wants to connect to a channel, it has to specify a provider for that channel. So, when the app just knows the channel name, and does not know which provider to use, there must be a way for it to automatically find out which provider to use, possibly following a site-specific policy. To allow querying for channel availability, the provider interface must have a function that queries the underlying name resolution mechanism of its service, without connecting to it. So the "Serial name resolution" provider asks all providers that registered with it, always waiting for an answer before asking the next provider: "Do you have a channel of this name?" The "Parallel name resolution" provider asks all providers that registered with it in parallel, connecting to the first positive answer it gets. > And I guess you are saying that approximately, plugins will correspond > to providers, since the "V3" plugin would be expected to verify V3 > PVs, and the "V4" plugin would be expected to verify V4 Pvs. But it is > not necessarily so, for example in your 3rd scenario below, the DS > plugin may answer V3 or V4. The provider must be able to connect to a named channel. A "V3" or "V4" provider will just connect through its service. A "serial", "parallel", or "DS" provider will connect to whatever its algorithm resolves as the provider for that channel. >> 2. Parallel name resolution >> Queries all providers that registered with it in parallel. Returns >> the first that answers. > As 1, but the client side plugins a queried in a parallel. >> 3. Directory server based >> Queries the directory server. Returns the answer it got from DS. > Here I think you mean one such client side plugin of the pvAccess > client agent, could be one that uses the DS to acquire the provider of > a PV. And it could be used in either the serial or parallel cases above. See above: a provider connects to a channel. > I take it the parallel case avoids the issue of having to wait a long > time for the UDP broadcast to timeout? The serial case implements "strict priority", the parallel case implements "any" (i.e. "whoever answers first"). The parallel resolver is faster, as the serial has to wait for every option to time out before going to the next one. The pluggable API in combination with functional provider plug-ins allows to set up auxiliary (even complicated) policies by simple configuration, without having to implement every policy in a separate piece of code. A slightly worse performance (going through multiple plugged API calls) will only affect the time for setting up a channel, not an existing connection. Cheers, ~Ralph >> >> Now the system configurator can easily create complicated policies >> just by plugging things. >> >> E.g. given three real providers (V4, V3, Tango), to implement a >> policy that reads: >> >> Use V4 or V3 or Tango, if app explicitly specifies it. >> Otherwise, first query the directory server. >> If that doesn't answer, first do a name resolution on both V4 and V3, >> then (if no answer) try Tango. >> >> One would set up the following provider structure >> >> app +--- prov1: Serial name res +--- prov1: Directory server >> | +--- prov2: Parallel name res +--- >> prov1: V4 >> | | \--- >> prov2: V3 >> | \--- prov3: Tango >> +--- prov2: V4 >> +--- prov3: V3 >> \--- prov4: Tango >> >> Simple and powerful! >> ~Ralph >> ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom |