Experimental Physics and
Industrial Control System

[email protected] · Tue, 18 Nov 1997 08:45:50 -0700 (PDT)

Hello -

I've found a problem with 3.12.2 CA repeater on both our VAX and AXP 
platforms running OpenVMS 6.2 and MultiNet V4.0 Rev B-X.  This problem 
results in either IOC reconnect problems or problems connecting to a newly 
booted IOC if the IOC was down when the CA client was started up.  The
problem is NOT related to the fast-booting-IOC reconnect problem reported
by Jeff Hill a few weeks ago.

I believe the problem is in the MultiNet software and reported it to them 
last week.  In the meantime, I've made a simple change to CA repeater to 
get around this bug.  Details follow in this message.  I'd be interested
to know if anyone else (using OpenVMS) has seen this problem?  Perhaps
I have a setup or build problem?  If MultiNet does not come up with a 
solution, can CA repeater be changed permanently to get around it?

Thanks,

Stephanie Allison   [email protected]
===========================================================================

Problem
-------

When multiple CA clients are registered with CA repeater and one of the
clients exits, the next time CA repeater forwards an IOC beacon, it will 
receive a bad status (with ECONNREFUSED errno) from the "send" call for 
all clients it sends to after the one that has exitted.  Depending on
the order that the clients registered and the position of the closed client 
in the list, it may take a few beacons for CA repeater to close all
sockets, but ultimately ALL sockets are closed and beacons are no longer
forwarded to the clients that are still up.  

The clients that no longer receive beacons now go into some sort of polling
mode with the IOCs with which they are connected.  My experience is that 
clients that are doing straight periodic gets at some slow rate will usually 
reconnect after an IOC boots.  However, recently I've added clients that
do monitors and they usually do NOT reconnect.

Solution
--------

I took the CA repeater code from patch 7 of 3.12.2.  A routine called
verifyClients has been added, apparently for some problem with the Solaris
platform.  In the fanOut routine of repeater.c, instead of closing the
socket and removing the client from the list on a bad send, I set a
"verify" flag to TRUE.  At the end of fanOut, if the "verify" flag is
set, verifyClients is called and sockets are properly closed or left
open.

I have reported this problem (with additional detail like TCPDUMP's)
to Process Software.  It is PSC #1929.  When (if?) I get a resolution,
I'll forward it on to tech-talk.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System