This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Open sockets non-overlapped?


On May 19 16:56, Dave Korn wrote:
> On 19 May 2006 16:20, Lev Bishop wrote:
> > It makes it so that cygwin sockets can be passed usefully to windows
> > processes. Eg:
> > $ cmd /c dir > /dev/tcp/localhost/5001
> > However, it's not perfect -- if the windows process just exits, then
> > the connection is reset, not shut down gracefully.  
> 
>   Well, if the windows process just exits, that is exactly what it has done.
> A socket should be shut down gracefully if the app calls shutdown(), and if it
> just calls close() the socket should be reset.  That's what "gracefully"
> means.
> 
> > Playing with
> > SO_LINGER doesn't seem to help here. Only way I can think of to make
> > it work would be to have the cygwin stub that waits for windows
> > processes to exit, to keep a handle on the socket, poll for when the
> > windows process closes the socket (using NtQuerySystemInformation
> > SystemHandleInformation?) and when it does, close down the socket
> > gracefully.
> 
>   It probably shouldn't be made to "work" because that would be altering the
> semantics of sockets. 
>  
> > Anyway, this adds new functionality and doesn't seem to break anything
> > that worked before.
> 
>   What, you've tested /everything/ that worked before?  ;)
> 
> http://cygwin.com/ml/cygwin/2005-03/msg01003.html
> ------------------------quote------------------------
> "If you create a socket using the Winsock 2 WSASocket API and you need to
> apply a timeout in receive or send operations on the socket, you must
> specify the WSA_FLAG_OVERLAPPED flag in the WSASocket call."
> 
> >From the MSDN website article
> http://support.microsoft.com/default.aspx?scid=kb;en-us;181610.
> ------------------------quote------------------------
> 
>   Are we /sure/ cygwin doesn't *depend* on overlapped sockets?  In particular,
> can a non-overlapped read be interrupted by a signal?  Have you tested this
> vs. both blocking and non-blocking sockets?  This seems to me to be a highly
> risky change; I'd like to know what testing you've done.

I found that using WSASocket(!OVERLAPPED) instead of socket results in
sshd misbehaviour (scp takes a long time to start copying files, an
interactive logon doesn't print the prompt until the user presses the
return key).  I didn't try to debug this, lazy as I am.

Additionally, I'm really curious *why* opening the socket without the
overlapped attribute should create a socket being more useful to native
Windows processes than standard, overlapped attributed sockets.  After
all the only visible difference is that a socket with the overlapped
attribute set can use overlapped operations, which the non-overlapped
socket can't.  It does not mean that overlapping I/O is forced on the
socket.  It's just adding a capability.

Actually, with a matching server listening on port 5001 (nc -l -p 5001),
I don't see any difference between using socket or WSASocket in the `cmd
/c dir > /dev/tcp/localhost/5001' example.  In both cases cmd refuses to
send anything useful to the server, printing "There is not enough space
on the disk."


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]