Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Fri, 24 Sep 2010 10:01:15 -0400

 Hello Pam,
I would select a free range of ports (actually two: one for the IOCs,
one for their procServ console ports). looking at the IANA document of
registered port numbers. [1]

Then I would add the selection of port numbers to the script that
handles the creation of a new soft IOC: it would scan the configuration
files of existing soft IOCs for the ports in use, choose free ports, and
write those into the configuration for the new soft IOC.
You should choose a layout where each soft IOC has its own configuration
file (for environment vars, ports, and other config data) in a
well-known location, so that adding and removing soft IOCs is done by
adding and removing files, not by editing files. That makes soft IOC
administration, distributing soft IOCs via package managers, and
scanning for the ports in use a lot easier.
As for the name resolution by directed UDP issue mentioned by Anze:

Solution 1 is to not use UDP broadcast, but multicast for name
resolution (Jeff mentioned this). The rsrv server (IOC) has to be
changed to support this.

Solution 2 is to use virtual network interfaces, and have each soft IOC
bind its server to a different IP. The rsrv server (IOC) has to be
changed to support this.

Solution 3 is to use a name server. Clients do not have to use UDP name
resolution at all in that case.
Just my 2 cents....
Ralph
[1] http://www.iana.org/assignments/port-numbers

On 24.09.2010 09:32, Pam Gurd wrote:

Perhaps I should be more clear. When I was at the SNS, we had
multiple soft IOCs running on each of several servers. We used the
EPICS_CA_SERVER_PORT environment variable to give each one a unique
port; however, this solution was, and continues to be, up to the
goodwill and good management of the IOC engineer. (I have a private
message from Kay, but I should get his permission before I share it.)
I was wondering whether anyone had a more structured approach.

I like the idea of separating functions by IOC, having lots of IOCs.
You can get permission to reboot most of the applications that way,
and leave the essential, unbootable, functions alone.

Pam.

----- Original Message -----
From: Anze Zagar <[email protected]>
Date: Friday, September 24, 2010 3:00 pm
Subject: [Fwd: RE: Soft IOCs and Port Numbers]
To: Pam Gurd <[email protected]>
> Hi Pam,
>
> This answer was not sent to EPICS Tech Talk but rather to me directly,
> so I'm forwarding it FYI.
>
> Cheers,
> Anze.
>
>
> -------- Forwarded Message --------
> From: Touchard Dominique <[email protected]>
> To: Anze Zagar <[email protected]>
> Subject: RE: Soft IOCs and Port Numbers
> Date: Fri, 24 Sep 2010 13:45:02 +0200
>
> o) Do something with modular epics and have only one IOC application
> running, hosting all the required IOCs as modules.
>
> Hi Anze,
>
> As far as I'm concerned, for the SPIRAL2 control command
> project, we has organized our software implementation with EPICS
> modules. An application is an IOC. An equipment interface is a
> module. An IOC application controls a facility line section or
> function.
> I should say that I'm a little bit curious. On the other way,
> why do you need few IOCs on the same host? Is it really a need,
> a constraint caused by a lack of implementation method or by an
> unmanaged(able) integration process?
>
> Dominique Touchard.
>
> -----Message d'origine-----
> De : [email protected] [mailto:tech-talk-
> [email protected]] De la part de Anze Zagar
> EnvoyÃ : vendredi 24 septembre 2010 13:02
> Ã : [email protected]
> Cc : [email protected]
> Objet : RE: Soft IOCs and Port Numbers
>
> Hi Matthew,
>
> Actually the issue is not on client side. CArepeater is used for
> clientapplications to share the beacon UDP port (e.g. EDM
> screens and also
> IOCs because they can be clients to one another...). We are wondering
> here, how to host multiple soft IOCs on the same computer, possibly
> sharing the same UDP CA request port. For broadcast UDP packets
> this is
> not really an issue, because Linux UDP stack is implemented in
> such a
> way that it by default fans out the packet to all services
> running on
> that particular port. Though, I'm not convinced that this is really
> standard UDP stack behavior and that we have any guaranties it will
> still work with future versions of Linux kernel. The second
> problem is
> that at some stage ITER may also want to configure some client
> to send
> unicast requests. Then it will for certain not work on Linux
> because in
> that case only one IOC will in fact receive the request.
>
> I see a few possibilities here:
> o) Ignore the problem and assume that in ITER broadcast UDP will
> alwaysbe used and there will be no problems in future. This is
> also ok if we
> assume that at some stage they will switch to EPICS v4 where port
> sharing will no longer be an issue.
> o) Do something with modular epics and have only one IOC application
> running, hosting all the required IOCs as modules.
> o) Assign different ports to different IOCs. This will very likely
> course cause a lot of other manageability issues.
>
> Cheers,
> Anze Zagar.
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System