EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Channel access problem on cygwin IOC
From: "Jeff Hill" <[email protected]>
To: "'Mark Rivers'" <[email protected]>, <[email protected]>
Date: 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




References:
RE: Channel access problem on cygwin IOC Mark Rivers

Navigate by Date:
Prev: RE: Channel access problem on cygwin IOC Mark Rivers
Next: Possible improvements to simulation mode [patch] Denison, PN (Peter)
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Channel access problem on cygwin IOC Mark Rivers
Next: RE: Channel access problem on cygwin IOC Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024