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 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?


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