Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 29 Sep 2005 19:09:47 -0600

Correction

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

I must admit that I 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.

> -----Original Message-----
> From: Jeff Hill [mailto:[email protected]]
> Sent: Thursday, September 29, 2005 6:55 PM
> To: 'Mark Rivers'; [email protected]
> Subject: RE: Channel access problem on cygwin IOC
> 
> 
> 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