Subject: |
EPICS V3 PV name length limits and how to get around them |
From: |
Benjamin Franksen via Core-talk <[email protected]> |
To: |
EPICS Core-Talk <[email protected]> |
Date: |
Mon, 19 Nov 2018 15:30:38 +0100 |
Hi everyone
the EPICS version 3 database will probably stay with us for some time
yet, considering all the existing device supports and drivers.
Similarly, Channel Access is not going to die soon, given that many
sites still use ancient display managers and other clients that aren't
easily ported to a new protocol.
We (Götz and me) just had an idea how to circumvent the existing
limitations in CA and in the EPICS (V3) database regarding the length of
record names and more generally PVs and therefore link fields. The idea
is quite simple: instead of the name itself, allow to use a hash sum of
the name, concretely the SHA1 of the clear text name, ASCII encoded
using Base64. The clear text name can then have arbitrarily many
characters. SHA1 has 20 bytes, so its Base64 encoding uses at most 27
bytes. This leaves enough room for field name, link options, and a
special character that signifies that this is a hashed name and not a
clear text name. The IOC can internally use a table to allow look up of
the clear text name given the hashed name. However, note that conversion
between hashed and clear text names on the IOC is purely for convenience
e.g. when using command line tools like dbpr or dbl. It is not needed
for record processing or CA.
The CA client library could be extended to handle PV names longer than
say 29 bytes by hashing them transparently. So what goes over the
network is only the hashed name, but the programs that /use/ the CA
client library need not know or care.
Cheers
Ben
Attachment:
signature.asc
Description: OpenPGP digital signature
- Replies:
- Re: EPICS V3 PV name length limits and how to get around them Michael Davidsaver via Core-talk
- Navigate by Date:
- Prev:
Jenkins build is back to normal : EPICS-7 #161 Jenkins EPICS PSI
- Next:
Re: EPICS V3 PV name length limits and how to get around them Michael Davidsaver via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Compression in pvAccess Marty Kraimer via Core-talk
- Next:
Re: EPICS V3 PV name length limits and how to get around them Michael Davidsaver via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|