Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: RE: Problems with CA in a WAN environment
From: johill@lanl.gov (Jeff Hill)
To: "Stefan Hippler" <hippler@mpia-hd.mpg.de>, <tech-talk@aps.anl.gov>
Date: Mon, 13 Sep 1999 17:59:30 -0600
Stefan,

It is difficult to determine the cause of your troubles. With the
information available I do observe that:

1) CAU client found the PV on the IOC
2) IOC server finished its normal PV connect sequence
3) IOC server never received a CA get request from the CAU client
4) CAU client disconnected (probably because it deleted
	the channel)

As I recall, the "cau" channel access client side application has a
short self imposed timeout that it uses when it is waiting for a response
to its "get" command. This program is probably almost always used on
a LAN. Perhaps it is timing out before it receives the connect sequence
response from the server.

To fault isolate you could try the following:

1) First verify that everything works correctly on the LAN that your
IOC is connected to.

2) Recompile "cau" with a longer "ca_pend_io()" timeout. If this solves
the problem we would be interested in reintegrating your changes into
the distribution. Alternatively, just try a different CA client which
is more robust in a WAN environment such as DM/EDD, MEDM, ALH, etc.
Basically
any of the clients which allow a channel to reconnect when contact is
temporarily
lost with the server will perform well in a WAN environment with long
propagation delays.

If this does not help then please send additional information such
as the version of EPICS, and output from the Solaris command
"snoop between hostXxx IOCyyy". This command will not work well
unless it is run on a host that is on the same network hub as
the host that it is watching (network switches will make it more difficult
to observe network traffic), and you will need to be root. If your host
is not Solaris then you may find that the similar commands "tcpdump" or
"etherfind" may be available.

Jeff



>
> I have a problem with channel access in a WAN environment and would like
> to ask the experts whether
> they have an idea on how to trace the problem.
>
> I have carefully checked all environment variables and timeouts and my
> guess is that the messages from
> the CA server do not reach the CA client (the other direction seems to
> work).
>
> On my CA server box I was setting CASDEBUG to 3.
> On the client side I was using cau to retrieve an epics record
> (mpia:tvGuiderY).
> I tried longer timeouts but without success.
> Below are the log records.
>
> Thanks
> /Stefan/
>
> ========
> CA client:
> ========
> cau> get mpia:tvGuiderY
>
> =================
> CA servers messages:
> =================
> 0xce42b4 (CA UDP): CAS: Sending a message of 0 bytes
> 0xce42b4 (CA UDP): CAS: cast server msg of 32 bytes
> 0xce42b4 (CA UDP): CAS: from addr 95d928df, port cf26
> 0xce42b4 (CA UDP): CAS: Parsing 32(decimal) bytes
> 0xce42b4 (CA UDP): CAS: cmd=6 cid=0 typ=5 cnt=6 psz=16 avail=0
> 0xce42b4 (CA UDP): CAS:         N=1 paddr=0
> 0xce42b4 (CA UDP): CAS: Sending a message of 24 bytes
> 0xce42b4 (CA UDP): CAS: cast server msg of 32 bytes
> 0xce42b4 (CA UDP): CAS: from addr 95d928df, port cf26
> 0xce42b4 (CA UDP): CAS: Parsing 32(decimal) bytes
> 0xce42b4 (CA UDP): CAS: cmd=6 cid=0 typ=5 cnt=6 psz=16 avail=0
> 0xce42b4 (CA UDP): CAS:         N=1 paddr=0
> 0xce42b4 (CA UDP): CAS: Sending a message of 24 bytes
> 0xc486fc (CA client): CAS: Creating new udp client
> 0xc486fc (CA client): CAS: converting udp client to tcp
> 0xc486fc (CA client): CAS: Recieved connection request
> 0xc486fc (CA client): from addr 95d928df, port cd71
> 0xc486fc (CA client): CAS: Parsing 80(decimal) bytes
> 0xc486fc (CA client): CAS: cmd=20 cid=0 typ=0 cnt=0 psz=8 avail=0
> 0xc486fc (CA client): CAS:      N=1 paddr=0
> 0xc486fc (CA client): CAS: cmd=21 cid=0 typ=0 cnt=0 psz=8 avail=0
> 0xc486fc (CA client): CAS:      N=2 paddr=0
> 0xc486fc (CA client): CAS: cmd=18 cid=0 typ=0 cnt=0 psz=16 avail=6
> 0xc486fc (CA client): CAS:      N=3 paddr=0
> 0xc486fc (CA client): CAS: Sending a message of 32 bytes
> 0xc486fc (CA client): CAS: Parsing 16(decimal) bytes
> 0xc486fc (CA client): CAS: cmd=10 cid=0 typ=0 cnt=0 psz=0 avail=0
> 0xc486fc (CA client): CAS:      N=1 paddr=0
> 0xc486fc (CA client): CAS: Sending a message of 16 bytes
> 0xc486fc (CA client): CAS: nill message disconnect
> 0xc486fc (CA client): CAS: Connection 5 Terminated
>
> ========
> CA client:
> ========
> error on search for mpia:tvGuiderY
> couldn't open mpia:tvGuiderY
> CA.Client.Diagnostic..............................................
>     Message: "Network connection lost"
>     Severity: "Info" Context: "156.156.156.156"
> ..................................................................
>   cau:
>
>



References:
Problems with CA in a WAN environment Stefan Hippler

Navigate by Date:
Prev: RE: SENS stack vs EPICS Alan Biocca
Next: Problems with installing interviews Lifang Zheng
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Problems with CA in a WAN environment Stefan Hippler
Next: problems with downloading EPICS Lifang Zheng
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·