Re: multiple servers on the same (loopback) interface

[D Peter Siddons <siddons@bnl.gov>]

I had a similar problem a couple of weeks ago. The fix for that was to 
add entries in the /etc/hosts file to provide the reverse lookup.
Pete.

On 07/09/2013 02:46 PM, Mark Rivers wrote:
> This is probably the problem of DNS resolution timing out because there is no DNS server to do the reverse DNS lookup on that interface.
>
> Mark
>
>
> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Jameson Graef Rollins
> Sent: Tuesday, July 09, 2013 1:42 PM
> To: Kasemir, Kay; tech-talk@aps.anl.gov
> Subject: Re: multiple servers on the same (loopback) interface
>
> On Tue, Jul 09 2013, "Kasemir, Kay" <kasemirk@ornl.gov> wrote:
> > The first IOC will serve on TCP port 5065.
> > The second one can't do that, so you get the warning Configured TCP port was unavailable, ...Using dynamically assigned TCP port 34497.
> > Both will try to listen to UDP search requests on the same port, then reply with the TCP port that they actually use, so all should be fine.
> >
> > BUT: Because of a quirk in most network kernels only one of them will actually see those UDP search requests. For me it's usually the IOC started _last_.
> >
> > If you want your clients to send search requests to all IOCs that are listening on the UDP port, you need to send a broadcast. Search requests sent to a specific IP address will only reach one of the IOCs listening on that IP.
> >
> > You can try setting the EPICS_CA_ADDR_LIST=255.255.255.255.
> > With localhost, that may not be possible, so you'll have to setup some network interface, maybe leave it disconnected, but it must have an IP address and most important a broadcast address.
> Hi, Kay.  Thanks for the suggestion.  This is a possibility that I
> considered, but since it requires administrative privileges to create
> and configure the dummy interface it's less than ideal for a generic
> testing infrastructure.
>
> That said, I did give it a try and it does sort of work.  The dummy
> interface is 127.2.0.1, and both servers bind to it.  However, the
> client access is very slow:
>
> 0$ time EPICS_CA_ADDR_LIST=127.255.255.255 EPICS_CA_AUTO_ADDR_LIST=NO caget -t TEST0:FOO
> 0
>
> real	0m6.292s
> user	0m0.000s
> sys	0m0.012s
> 0$
>
> The initial response is fairly quick, but there's a long delay before
> process returns.  Is using a broadcast address know to introduce a
> noticeable delay like this?
>
> jamie.
--
D. Peter Siddons
Detector Development Group Leader
Bldg. 535B
Photon Sciences Directorate,
Brookhaven National Laboratory
Upton, NY 11973

email: siddons@bnl.gov
Phone: (631) 344-2738