Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 29 Sep 2005 18:54:41 -0600

Mark,

> CAC: Unable to connect because "Connection refused"

This might occur when the IP kernel thinks that it does not have a server on
the CA port, or that too many circuits connect at once and backlog exceeds
the listen count.

Another possibly is that an IOC was connected before and was restarted. When
that happens there are some subtleties related to SO_REUSEADDR which
basically override the IP kernel's preference to not allow a service to
reuse a TCP port until a long timeout has expired (and all packets traveling
around the internet heading for that port have either arrived at the
server's host or exceeded TTL). People seem to abhor the default behavior
and so we have had SO_REUSEPORT enabled for a long time, but perhaps this
isn't working correctly with cygwin.

I notice this code in the native win32 port.

/*
 * Note: WINSOCK appears to assign a different functionality for 
 * SO_REUSEADDR compared to other OS. With WINSOCK SO_REUSEADDR indicates
 * that simultaneously servers can bind to the same TCP port on the same
host!
 * Also, servers are always enabled to reuse a port immediately after 
 * they exit ( even if SO_REUSEADDR isnt set ).
 */
epicsShareFunc void epicsShareAPI 
    epicsSocketEnableAddressReuseDuringTimeWaitState ( SOCKET s )
{
}

Personally, I don't have any experience with the cygwin port of EPICS. I
must admit that I don't routinely test the native port of EPICS on windows,
but not the cygwin port which is in essence POSIX running on top of win32.
This is mostly because there are always too many things to get done.

In the past when I did try that version there were some mysterious behaviors
related to sockets w/o any clear workarounds, but that was quite some time
back when cygwin first started out, and cygwin is definitely improving all
the time.

However, when a person wants to use cygwin on windows I suspect that what
they want is the cygwin environment, and not necessarily the cygwin port of
EPICS which involves additional overhead routing the EPICS OSI layer first
to cygwin posix and then on to win32 and winsock, and no way to concentrate
our attention on the specific OS features that EPICS needs. With the native
port the EPICS OSI layer goes directly to win32 and winsock. The native port
(implementation of the EPICS OSI layer) is carefully optimized and tested
for windows. 

I don't have anything against cygwin. It's really a great idea avoiding the
draconian limits built into MS's "POSIX subsystem" - which no one seems to
really use. However I like being able to optimize the OSI layer for win32,
and I'm not ecstatic about having to chase bugs in two ports. 

One way to avoid having to test and maintain two versions would be to not
use cygwin-x86 (which was I think formerly incorrectly called
win32-x86-cygwin) and instead use win32-x86-cygwin (which consistent with
other OS should mean build EPICS for win32-x86 with the cygwin compiler).
Unfortunately, the config files for win32-x86-cygwin do not yet exist, but I
suspect that the effort required to create them might be less than the long
term effort required to maintain two ports of EPICS on windows. One possible
peril with this idea might be mix ups occurring when win32 posix-like header
files get confused with cygwin posix header files (this is probably a
non-issue with sockets). There could also be problems with library search
paths. When setting up the config files these are issues to be cognizant of.
The cygwin GNU C/C++ RTL is probably going to work fine with the native
port.

There's my two cents worth.

Jeff

> -----Original Message-----
> From: Mark Rivers [mailto:[email protected]]
> Sent: Thursday, September 29, 2005 12:53 PM
> To: [email protected]
> Subject: Channel access problem on cygwin IOC
> 
> I am having an intermittent problem with channel access on a cygwin IOC.
> Sometimes when the IOC starts everything works fine, but sometimes I get
> the following behavior:
> 
> - No channel access clients are able to connect to any PVs on the IOC.  I
> get the following types of errors:
> 
> corvette> caget dxpXMAP:med:mca1.ERTM
> CAC: Unable to connect because "Connection refused"
> CA.Client.Exception...............................................
>     Warning: "Virtual circuit disconnect"
>     Context: "164.54.160.5:5064"
>     Source File: ../cac.cpp line 1145
>     Current Time: Thu Sep 29 2005 13:49:55.763202000
> ..................................................................
> Channel connect timed out: 'dxpXMAP:med:mca1.ERTM' not found.
> 
> 
> - casr on the IOC produces the following, which seems OK to me.
> epics> casr 50
> Channel Access Server V4.11
> No clients connected.
> UDP Server:
> UDP 164.54.160.111:50650(): User="", V4.11, 0 Channels, Priority=0
>         Task Id=0x103987b0, Socket FD=8
>         Secs since last send  34.40, Secs since last receive   0.12
>         Unprocessed request bytes=16, Undelivered response bytes=0
>         State=up
>         168 bytes allocated
>         Send Lock
> epicsMutexId 0x10399060 source ../caservertask.c line 673
> ownerTid 0x0 count 0 owned 0
>         Put Notify Lock
> epicsMutexId 0x10399158 source ../caservertask.c line 674
> ownerTid 0x0 count 0 owned 0
>         Address Queue Lock
> epicsMutexId 0x10399250 source ../caservertask.c line 675
> ownerTid 0x0 count 0 owned 0
>         Event Queue Lock
> epicsMutexId 0x10399348 source ../caservertask.c line 676
> ownerTid 0x0 count 0 owned 0
>         Block Semaphore
> There are currently 1176 bytes on the server's free list
> 7 client(s), 0 channel(s), 0 event(s) (monitors) 0 putNotify(s)
> 0 small buffers (16384 bytes ea), and 0 jumbo buffers (16408 bytes ea)
> The server's resource id conversion table:
> Bucket entries in use = 0 bytes in use = 16404
> Bucket entries/hash id - mean = 0.000000 std dev = 0.000000 max = 0
> The server's array size limit is 16408 bytes max
> Channel Access Address List
> 164.54.160.255:5065
> 
> Any ideas on what the problem could be, or how to track it down?  This is
> a new problem, I have been running cygwin IOCs for many months with no
> problem.  I am developing a new application that has started to produce
> these symptoms.
> 
> Thanks,
> Mark
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System