This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: Open sockets non-overlapped?
On 6/12/06, Corinna Vinschen wrote:
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.
Strange. I don't run sshd, but I've been using this patch for a while
now and not noticed any problems. Maybe I'll try installing sshd one
of these days and see if I see those issues you describe.
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.
It doesn't make it any less useful to native processes _as a socket
handle_ but it does make a difference when the native processes use it
_as a file handle_. As you know, the semantics of WriteFile() et al
change completely depending on whether they get an overlapped handle
or not (eg the LPOVERLAPPED parameter either _must_ be null or _must
not_ be null, on 95/98/Me) . And there seems to be no way to tell
whether a handle you've inherited was opened overlapped or not (short
of using the NT API: NtQueryInformationFile FILE_MODE_INFORMATION) and
no way to reset the mode once the file has been opened. So
applications are effectively forced to assume their GetStdHandle()s'
are non-overlapped.
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."
Hmph. It works for me. Must be some difference in our configurations,
windows versions, etc. I note that msdn warns that using socket
handles as file handles is an optional feature and not all providers
support it. I guess the provider must be both a Winsock provider and
also a file-system driver in order to make this work. Maybe you have
some LSPs on your machine or something?
Lev