Open sockets non-overlapped?

[Lev Bishop]

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