Re: Help interpreting CA protocol

[Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>]

On 2/26/25 13:27, Nicholas Devenish via Tech-talk wrote:
> Hi All,
>
> I've been studying the CA protocol documentation (https ://docs.epics-controls.org/en/latest/internal/ca_protocol.html), attempting to implement the
> CA protocol as a learning exercise to become more familiar with EPICS. I've
> found a few points of confusion that I'd appreciate help resolving
Only a few?  I think you are doing well then.


> - I think in
> other places the source is referred to as the final word,
Yes.  That CA protocol document was written well after the CA protocol was designed
and released into the world.  So it may best be seen as the accumulated understanding
of people going through the same exercise you are undertaking.  So please consider
contributing!

https://urldefense.us/v3/__https://github.com/epics-docs/epics-docs/blob/master/internal/ca_protocol.rst__;!!G_uCfscf7eWS!fJopMApca9YUBFQWPamZoPf7AlIHc1lRdWpirPM0ftc9t0NDaEkwPmiIuXUbB3vmwgD7CaF6pBAstRePMMkrWtOIVw$ 

> but I've not yet gotten
> good at finding things/navigating through the code base, (so tips on that/documented structure would also be welcomed).
With CA, I found it simpler to understand the server side first.
This lets you put off understanding eg. the UDP search process,
and hand-off to TCP, which makes clients complicated.

In an IOC, the CA server implementation is known internally as RSRV.

https ://github.com/epics-base/epics-base/tree/7.0/modules/database/src/ioc/rsrv

You might look at tcpJumpTable[] and udpJumpTable[] in camessage.c


> Apologies for several large questions:
>
> -----
>
> CA_READ / CA_READ_NOTIFY Responses
>
> The response is listed (for both responses) as parameter1 being "Server ID": https ://docs.epics-controls.org/en/latest/internal/ca_protocol.html#id23, however in the "ECA Error/Status codes section", it explicitly mentions that return codes are sent in CA_PROTO_READ_NOTIFY, and the (invaluable) Wiresharks EPICS plugin at https ://github.com/mdavidsaver/cashark does indeed list parameter1 as being the ECA return code.
>
> Is this just a typo in the protocol documentation, and this field should indeed be the Status code instead of the Server ID?
https ://github.com/epics-base/epics-base/blob/7bd3e7aa2e2483bc4a2878742504fac2651487b0/modules/database/src/ioc/rsrv/camessage.c#L554-L562

This actually goes back to 70de17474b67a9e4969f7aadf355435cf88527d0.
So the documented usage stopped being correct and complete 24 years
ago.  Before the CA protocol document was started even.



> If not, presumably I send a CA_PROTO_ERROR instead of the expected response?
imo. this question is one of the ambiguities of the CA design.  The
best advise I can give is to consider PROTO_ERROR as a second best
option, and look for another way to report an error, but be aware that
there may not be one.


> -----
>
> CA_PROTO_SEARCH:
>
> In the "comments" section `CA_PROTO_SEARCH` rather definitively says:
>
>      > It is illegal to specify `DO_REPLY` flag whenever the message is sending as UDP datagram, regardless of whether broadcast or multicast is used."
>
> However, immediately below it says:
>
>      > Reply flag will be __generally__ DONT_REPLY when searching using broadcast
>
> The choice of "generally" seems to imply that it can be set on a UDP search? In addition, the description for CA_PROTO_NOT_FOUND response says that it _is_ sent over UDP:
>
>      > Sent in response to CA_PROTO_SEARCH, but only when its DO_REPLY flag was set. Sent over UDP.
>
> Is this supposed to be sent if searching via UDP, and the notify flag is set, or ignored?
Another bit of history.  Consider that CA protocol was designed
before the Morris worm.  When DOS was just an operating system.

I would recommend not sending negative replies to SEARCH.
Especially not to a broadcast SEARCH!


> -----
>
> Shorter questions:
>
> - CA_VERSION lists several fields as "Must be 0". However, whilst sniffing the broadcast packets on our beamline network, I see quite a lot of searches where these fields have data in (and version is listed as 13). Are these malformed and should be ignored, or pragmatically replied to?
> - The ECA Error-status-code-table at https ://docs.epics-controls.org/en/latest/internal/ca_protocol.html#eca-error-status-codes lists `ECA_INTERNAL` as Severity "`CA_K_FATAL`". But this doesn't seem to be a valid severity (any more?). Should this read `CA_K_SEVERE`, or there is another (higher) value not documented by the severity code table?
I had not noticed this before.  It looks like this is real.
From the context and comments, I guess this is part of an
attempt to measure and throttle UDP traffic.  Maybe you
can figure out what Jeff was up to?

https ://github.com/epics-base/epics-base/blob/7bd3e7aa2e2483bc4a2878742504fac2651487b0/modules/ca/src/client/udpiiu.cpp#L920-L922


> Thanks,
>
> Nick Devenish
> (Diamond Light Source)