Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Fri, 30 Sep 2005 11:29:37 -0600

> -----Original Message-----
> From: Mark Rivers [mailto:[email protected]]
> 
> > Another possibly is that an IOC was connected before and was
> > restarted.
> 
> What exactly do you mean by this?  The cygwin IOC has indeeed been
> started and stopped many times.  

Sorry, I sent out that message yesterday evening a bit too quickly. I meant
that an active IOC is bound to the CA server port. If that IOC is restarted,
on UNIX systems that port is by default placed in TIME_WAIT state where it
can't be reused until a timeout expires (even if the socket is closed
gracefully). However, the CA server code turns off that behavior by setting
socket option SO_REUSEADDR. In the windows port this step is not required
(the TIME_WAIT unavailability behavior does not exist) and SO_REUSEADDR was
observed, at least on certain versions, to be harmful so we noop out the
relevant OSI call. On POSIX setsockopt SO_REUSEADDR *is* enabled. If that
was not filtered out by cygwin then you might experience the diseased
situation I once observed where two IOCs were actually allowed by the IP
kernel to be bound to the same TCP/IP port. I don't well remember the
specifics other than observing some bizarre behaviors when this occurred. 

> However, I have exited all channel
> access clients that are connected to that IOC, both on the local Windows
> machine and on other machines.  Does this matter?

Shouldn't.

> 
> Here is some more information which may be of interest:
> 
> - When I was having the problem an SNL program running in that cygwin
> IOC was able to connect to the PVs fine.  That is just a CA client,
> right?

When the CA client library communicates with local in-memory PVs it talks to
them directly using db_access, and bypasses socket communication altogether.

> - Other CA clients on the Windows machine were not able to connect.

They need socket communication.

> - Ohter CA clients on remote machines were not able to connect.

They need socket and IP communication.

> - Rebooting the Windows machine fixed the problem, at least for now.
> - The problem kind of seems like running out of a resource, perhaps with
> SO_RESUSEADDR as you suggested?

And if that does not take care of it then you must reinstall windows ;-)

Seriously, this might fix many things. Among them, this might have cleared
out a diseased situations where two IOCs were actually using the same TCP
port (because SO_REUSEADDR was allowed to be set by cygwin). 

> 
> One minor point is that cygwin is nice because I can set up soft links
> under cygwin so that the same configure/RELEASE files in every
> application work for Linux, vxWorks and cygwin.  That does not work for
> win32-x86 since one needs to use Windows syntax for paths, not Unix
> syntax.  cygwin also lets me install an ssh server on the Windows
> machine so I can do EPICS development on the Windows machine remotely
> with good performance, no need to be sitting in front of it.
> 

I install and run the cygwin tools on my PC also. Personally, I just check
out the relevant EPICS base files from a remote CVS repository onto my PC. I
don't try to share the files between UNIX and windows because the line
terminators invariably get clobbered if I do (CVS adjusts them for me
transparently). I'm not too worried about disk space. I seem to always have
many different versions of EPICS checked out from different branches.

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System