Experimental Physics and
Industrial Control System

[email protected] · Wed, 22 Mar 2000 10:45:30 +0100 (MET)

Jeff,

  >> I have a machine with six network interfaces to six different subnets.
  >> 
  >> I'm running six CA Proxy Gateways on that machine --- one for each
  >> subnet. All these Gateways differ on the client side, i.e. each Gateway
  >> has a different EPICS_CA_ADDR_LIST, but these settings aren't disjunct
  >> (each Gateway mirrors channels from an arbitrary number of the five
  >> other subnets).
  >> 
  >> How should I start caRepeater(s) to handle this situation correctly?
  >> 

  > If all of these servers are on the same port then there will be only one
  > CA repeater per client host.

Why does the caRepeater depend on the server port? I thought it is a
client side tool.

  > The CA repeater is a client side beast. It is started automatically by the
  > client and it normally requires no special configuration if it can be found 
  > by the client in its path.

Maybe I didn't make myself clear enough. Sorry.

My machine has six network interfaces into six subnets. So it has six IP
addresses (one in each subnet). Each subnet offers channels and needs
access to channels in the other nets. I run six Proxy Gateway processes:
all on the standard server port, one for each of the machine's IP
addresses. Each of the Gateways has a quite different configuration, as
well for the forwarded channels (genuine Proxy Gateway channel filter
list) as for the CA client side (EPICS_CA_ADDR_LIST; the client ports
are all standard). This is because no subnet wants its gateway to
forward local channels as this would lead to duplicate channels.

With the networks being called 'A' to 'F' (and the machine IP addresses
being A.5 to F.5) I would have six Proxy Gateways:

Server IP        Client ADDR_LIST

A.5                    B.255 C.255 D.255 E.255 F.255
B.5              A.255       C.255 D.255 E.255 F.255
C.5              A.255 B.255       D.255 E.255 F.255
...

The caRepeater just takes the CA beacon port as configuration. So when I
start one caRepeater, will it listen to all network interfaces?

When the Gateways get the forwarded beacons from the caRepeater, will
they filter it through their own CA_ADDR_LIST before retrying to
connect unresolved channels? E.g. if Gateway A gets a message that
there's a new CAServer on subnet A, it IMHO should _not_ try to reconnect
its unresolved channels, as subnet A is not within its CA_ADDR_LIST.

If one of my Gateways listens on a different port (Gateway CAC
configuration), will I have to start another caRepeater for the
different port? If yes, will the Gateways (or other CA clients) know
which caRepeater they have to connect to? How?

When you allow <IPaddress>:<port> addressing in CA_ADDR_LIST (which is
on your to-do-list), how will configuring different beacon ports work?
In this case the clients will have to connect to multiple caRepeaters,
right?

  > However, there is a known problem with the new ca server library
  > which I have mentioned earlier on tech-talk [...]

I'm aware of this and don't even dare trying to run multiple servers on
the same IPaddress/port combination (I have a certain feeling this would
_not_ work as expected).

Doesn't apply to my case anyway, as each Proxy Gateway runs on a
different server IP address.

  > On a related topic, it is possible for one CA server to attach to a
  > list of network interface cards specified by IP address in an
  > environment variable (see the doc in CONFIG_ENV), but the gateway
  > appears to have limitations which prevent this.

If you are really serious about this, I might perhaps start thinking
about trying to overcome these limitations in the Gateway.

  > It should be in principal possible to run one gateway which attaches
  > its server to some set of network interface cards and its client to
  > some other non-intersecting set of network interface cards and
  > therefore there would be no need for multiple gateways per host.

Only if the networks don't intersect, so it doesn't apply to my case,
right?

Sorry for the bother ....

Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System