1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: List all available PVs |
From: | Stainer Tom via Tech-talk <tech-talk at aps.anl.gov> |
To: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Tue, 27 Apr 2021 13:58:56 +0000 |
> I'd say in part that's because the EPICS network protocol is meant to be loosely coupled, kinda like web servers. > Anybody can start a new web server, email the URL to a friend, who can then open the new web page. > Similarly, you can start a new IOC, give the PV name to a friend who can then access the PV. > Out of the box, there is no need to add your web server to a central registry, just like there is no global EPICS PV name server. > There's also the question of what an IOC should publish for possible channel names, since in principle every record_name.field_name permutation can be a channel name, but many record are meant to be 'internal', not intended to be shown
on a display. > With web servers, Google will read the email that you send to your friend and put your new web site into its index, so there is pretty soon a way to locate your web site. Similarly, most EPICS sites add some service on top of IOCs to
catalog PV names into for example the Channel Finder. But those are layers on top of the basic web page or IOC, you're still free to add web server or IOC or just a new record to an existing IOC without need to "register" it.
> -Kay Hi Kay, That is a useful analogy, that helps in understanding the problem better, thanks. If I may continue with your analogy and the case of the web, then in this context there are web crawlers that exist for the sole purpose to index web sites and to see what is out there on the web (whether advertised or not). Similarly,
I would like to know how one would go about making such a crawler for PVA, which could or could not be used in combination with a central registry. At this point, I guess it is more curiosity than anything else to know if anyone has developed such a crawler
already, and what implications this has in terms of network traffic… I was thinking along the lines of a tool that you could run on a network using PVA that would find every available device/IOC/server exposing PVs over the network and return an associated tree of values, along with IP, port, (and even
access control info?), along with the PV list of course. Something that you could run overnight if it was too heavy but would generate an output combining pvinfo & pvlist i.e. Device1 @ 192.168.1.2:5075
Device2 @ 192.168.1.2:54778
Device3 @ 192.168.1.3:5075
….. From what I understand so far (and ignoring gateways) this could be perfectly possible to do by extending the pvlist tool, I would imagine that even with 1 million+ PVs this should still be achievable, or am I being naive? Kind regards, Tom |