[Fwd: 1.5.11-1: sftp performance problem]
Sat Sep 11 13:02:00 GMT 2004
On Sep 10 11:55, Bob Byrnes wrote:
> On Sep 10, 11:01am, XXXXXXXX@XXXXXX.XXX (Corinna Vinschen) wrote:
> > Hmm, I just found that this can't be quite valid anymore. Using
> > socketpairs is way faster, even when using Cygwin 1.5.10. I digged
> > in the openssh-unix-dev ML archives and the decision to switch to
> > USE_PIPES has been made 3 1/2 years ago. I'm wondering if it's
> > time to switch back to socketpairs...
> -- End of excerpt from Corinna Vinschen
> One really annoying consequence of socketpairs for sshd is that
> Windows-native (i.e. non-Cygwin) programs don't know how to write
> directly to sockets on stdout (or stderr0, so if you try to use
> them via ssh, their output silently disappears. You can see this
> by doing ...
> # no output
> cl -help
> # works normally
> cl -help | cat
> ... with an sshd that uses socketpairs instead of pipes.
Oh lord! I tried it with `net', `ping' and `nslookup', which are roughly
the only Windows applications I use on the command line, and all three
have no problems. I'm wondering how the above can happen since the
interactive application side is running in a PTY (which *is* a pipe),
not on socketpairs.
> I think OpenSSH uses pipes on most platforms by default, so I'm also
Only on those platforms which have known problems with (or no implementation
> somewhat concerned that the socketpair-specific code in OpenSSH might be
> a bit crufty.
Why? Socketpairs are in the same shape as any other socket connection
since they are using the same code. And I surely do care for socket
operations. See the ChangeLogs. What especially do you think is "crufty"?
> It's not obvious to me why socketpairs would be inherently faster
> than pipes. Maybe my latest patch exacerbated a longstanding but
> not-fully-appreciated performance problem ... I'd certainly be
> interested in improving that.
Glad to hear that. I'm looking forward.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:firstname.lastname@example.org
Red Hat, Inc.
More information about the Cygwin-patches