Experimental Physics and
Industrial Control System

"Johnson, Andrew N. via Core-talk" <[email protected]> · Mon, 19 Nov 2018 17:29:48 +0000

The CA protocol's channel name length is not limited by the size of the
NAME field in the IOC. I believe the limit is set by the size of the UDP
search packet and the MTU of the network path between the client and
server, because I don't think a search message can cross a packet
boundary (I haven't checked that though). With the server-side filters
added to Base-3.15.1 we have been sending names that are significantly
longer than the 60 character NAME field for some time (the NAME field
was marked size(61) in Base-3.14.0-beta2), so this is already proven.

Ben, what limitations are you trying to solve, and how do you know that
they actually exist?

- Andrew

On 11/19/18 10:56 AM, Michael Davidsaver via Core-talk wrote:
> Hi Ben,
> 
>> 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.
> 
> I'm a bit perplexed that overcoming an implementation limit of name
> length should involve what sounds like effectively a protocol change.
> In that it would prevent old and new clients/server from interoperating.
> Am I missing something?
> 
> 
> On 11/19/18 6:30 AM, Benjamin Franksen via Core-talk wrote:
>> 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
>>
> 
> 

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System