Experimental Physics and
Industrial Control System

"Ernest L. Williams Jr." <[email protected]> · Thu, 29 Sep 2005 21:46:19 -0400

On Thu, 2005-09-29 at 18:54 -0600, Jeff Hill wrote:
> 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).
We have been playing around with the open-source version of "Qt" for
WIN32 and have met a problem:
 --- The only supported open-source compiler for Qt on Windows is
something called "MinGW".  We went the path for a while of trying to
build EPICS BASE on WIN32 with MinGW, however we met some trouble.
Dave Thompson told me something to do with "pthreads" not being
supported.

Well, anyway we are back to MS Visual Studio .NET on Windows plus the
commercial version of Qt.
What a shame.   Maybe, we should pursue this again?

I agree with you that we should concentrate on getting the EPICS build
to happen with the cygwin compiler and maybe even MinGW.  We don't want
to pay Microsoft any longer.

> 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. 

Sounds good.

> 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