g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
<== Date ==> <== Thread ==>

Subject: Re: Several soft IOCs on one host
From: "Kasemir, Kay" <kasemirk@ornl.gov>
To: 胡建军 <hujj@impcas.ac.cn>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Fri, 30 Nov 2012 09:13:50 -0500
Hi:

>From: Jianjun
>Is it possible to deploy several soft IOCs on one host? If possible, how
>to differentiate them?

Yes, you can run multiple soft IOCs on one host.

I assume this is about IOCs with different PV names (records).
Not multiple instances of the same IOC, because you cannot have the same
PV name multiple times on the network.

Basically, you just start them: In one terminal window run "softIoc -d
first.db", in another terminal window run "softIoc -d second.db".
Eventually, you'll want to use something like procServ to capture their
console output, and to run the IOCs as Linux services, but same idea: Just
start multiple IOC processes.




As with EPICS in general, you don't differentiate between them at all.
Fundamentally, you never know where a PV "pv1" or "pv2" comes from. PVs
could come from the same IOC, from different IOCs, from different IOCs on
the same host, or different IOCs on different hosts.

You simply start the IOCs. Channel Access clients search the network for
PV names, the IOCs reply "I have that name", client and IOC connect, done.


Now there is some network related detail to be aware of:

When you start the first IOC, it uses the default Channel Access UDP port
5064 to listen for search requests, and default TCP port 5064 to serve
data.
So if a CA client sends a search broadcast to UDP 5064, that IOC will
reply "I know PV x, get the data on TCP 5064".

When you start the second IOC on the same host, it will also listen on UDP
5064, but it cannot re-use TCP 5064 because that's already taken by the
first IOC. So it will use some arbitrary free TCP port, say 58434. It will
reply to clients: "I know PV y, get the data on TCP 58434".

If you're on a local network, no firewalls, nothing special, this will
"just work".

The first issue arises when you add a firewall: You can open UDP and TCP
5064 to allow Channel Access traffic. But the second IOC will use some
arbitrary free TCP port, you can't predict it, and consequently you can't
open it in the firewall. You could try to set the EPICS_CA_SERVER_PORT of
the second IOC to say 5066 to you _know_ what to open in the firewall, but
this will cause the IOC to use 5066 for both UDP and TCP. So now all your
clients need to add "that_host_name:5066" to their EPICS_CA_ADDR_LIST ->
not practical, you cannot add each IOC to each client's address list.


The second issue is with setting EPICS_CA_ADDR_LIST. If you set it to
EPICS_CA_ADDR_LIST="first_host_that_has_several_soft_iocs:5064
other_host_that_has_several_soft_iocs:5064 .."
it will only find one IOC per host.
In principle, all the soft IOCs on a host will listen to UDP 5064 on their
host, but some quirk in most network kernels only  informs the program
that started _last_ of UDP traffic that was received on a shared UDP port.

You have to use a broadcast address list:
EPICS_CA_ADDR_LIST="broadcast_for_subnet1:5064 broadcast_for_subnet2:5064
.."
(since 5064 is the default EPICS_CA_SERVER_PORT, just
"broadcast_for_subnet1 broadcast_for_subnet2" is also OK)



==> If you run multiple soft IOCs on a host, do that on a subnets without
firewalls and list the broadcast addresses for all involved subnets.

If you do want firewalls, or if you want to control which host is on the
list and not use subnet broadcasts, you need to setup CA gateways:
EPICS_CA_ADDR_LIST="gateway1 gateway2 gateway3 .."

and have a gateway for each fire-walled subnet. Those gateways then each
use
EPICS_CA_ADDR_LIST="broadcast_for_my_subnet"



Thanks,
Kay





Navigate by Date:
Prev: CSS BOY left-mouse event Mogamad Amien Crombie
Next: Re: caRepeater object code not cross-compiled in R3.14.12.2 Jack Smith
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
Navigate by Thread:
Prev: RE: CSS BOY left-mouse event Chen, Xihui
Next: EPICS support for NewFocus 8752 controller? Fairley, Diane M.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·