Hi Stephen,
You might want to think a little bit about the CA repeater on this
system, especially if you're going to be running multiple IOCs or CA
clients on the same CPU.
There can only be one CA repeater running at once. When the CA client
library starts up it looks for a repeater by trying to bind a socket to
TCP port 5065; if that fails it assumes there is a repeater running
already, so it that. If the bind succeeds though it will fork a separate
process to run the repeater in. You probably don't want that repeater
process to be running inside your docker container, because CA clients
started after the IOC will now use that repeater, and if you shut down
the IOC's container those connections will be cut as well.
Better to start the repeater as a separate process, possibly in its own
container. The binary is called 'caRepeater' and is available from Base
in the usual bin directory. It needs to listen on 5065/udp and bind to
5065/tcp where all other local CA clients will connect to it. The other
client containers then do *not* need to listen on 5065/udp or 5065/tcp
but do have to be able to connect to 5065/tcp.
HTH,
- Andrew
On 07/04/2016 04:09 PM, Stephen Molloy wrote:
> Thanks Ralph,
> Your comment on UDP & TCP was the clue I needed. I had opened 5064 &
> 5065, but only for TCP connections. Opening them up for UDP as well
> allowed external connections. Using the following command to run the
> docker container did the trick,
> docker run -i -t ‹rm -p 5064:5064 -p 5064:5064/udp -p 5065:5065 -p
> 5065:5065/udp sdmolloy/ubuntu-playground:latest /bin/bash
>
> I¹m getting complaints about identical PV¹s being found on multiple
> servers, but I think this is a side effect of running on a VM.
>
> Thanks for your help,
>
> Steve
>
>
> On 04/07/16 17:02, "Ralph Lange" <[email protected]> wrote:
>
>> Hi Steve,
>>
>> A CA client uses ephemeral ports as originating port numbers, correct.
>> Ephemeral port numbers are indeed random, and cannot be predicted
>> reliably.
>>
>> However, if your container contains an IOC (CA server), opening ports
>> 5064&5065 (in the default setup) for both TCP and UDP should allow any
>> client outside the container to connect. (Not much different to a
>> container with a web service published at port 80.)
>> The CA client in the container would still use ephemeral port numbers
>> for outgoing connections - do you need to publish those?
>>
>> Cheers,
>> ~Ralph
>>
>>
>> On 04/07/2016 16:43, Stephen Molloy wrote:
>>> I¹m trying to build a Docker container for quick set-up and tear-down
>>> of EPICS instances, and I¹ve run into a problem. A CA client outside
>>> the container, but on the same host, cannot see any PV¹s served from
>>> inside the container.
>>> Looking at the network traffic with Wireshark, I can see that the
>>> server uses ports 5064 & 5065 as expected, but the ports used by the
>>> client seem to be relatively random. If I could predict them, or
>>> (even better) force them to be specific ports, then I could expose
>>> those ports in the Docker container and (hopefully) the client and
>>> server could communicate properly.
>>>
>>> Or perhaps this isn¹t the problem, and there is some other network
>>> issue getting in my way.
>>> (I¹ve successfully run several EPICS installations on this network and
>>> from this computer, so I am confident that this is an issue with the
>>> Docker set-up.)
>>>
>>> Hopefully I¹m on the right track with my thinking, and hopefully
>>> someone can let me know how to proceed from here?
>>>
>>> In case you¹re interested, I¹m documenting my work on my blog ‹
>>> http://www.smolloy.com/2016/07/easy-epics-implementation-with-docker/
>>>
>>> Thanks (again) for your time,
>>>
>>> Steve
>>>
>>
>
>
--
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
- References:
- Post numbers used by CA client Stephen Molloy
- Re: Post numbers used by CA client Ralph Lange
- Re: Post numbers used by CA client Stephen Molloy
- Navigate by Date:
- Prev:
Re: MRF EVG, EVR, and EVM's Linux Kernel modules Konrad, Martin
- Next:
Re: gddAppFuncTableStatus string pthomas
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: Post numbers used by CA client Mark Rivers
- Next:
MRF EVG, EVR, and EVM's Linux Kernel modules Jeong Han Lee
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
|