On Fri, Feb 15, 2008 at 12:27:19PM +0000, Darren J Moffat wrote: > Nicolas Williams wrote: > > Do we want to provide an option for the 'none' SSHv2 cipher? > > I don't. I think it is a very bad idea. However I would be willing to > reassess this after the networking changes have been done if they still > don't show good enough performance.
I agree. > Other things to consider are how to get ride of the pipe(2) between > sftp/scp and ssh on the client side. Also consider if it would help if > sftp-server were integrated into sshd on the server side. I agree. I think sftp-server could easily be integrated into sshd since it's entirely driven by input packets and it doesn't block (unless it's serving NFS, and even then, running the sftp-server in a separate thread would be fine). Its event loop should be easily modified to fit into sshd's, and all the process*() functions in sftp-server.c should be augmented to have all currently global state passed in (primarily the Buffer instances uses to interface with sshd). Integrating the SFTP client into ssh(1) will be more complicated since it will require creating an IPC between the actual sftp(1) and ssh(1), and it will erquire either running a thread in ssh for each SFTP channel or splitting many functions in sftp-client.c into pairs and adding a dispatch for the replies (but again, to avoid having ssh block on NFS threads would be better). > Basically I'm not convinced enough that the crypto (once we can use the > hardware) is actually the biggest performance problem with scp/sftp. Me either. I really think that the TCP auto-tuning issue is the most significant. BTW, we could implement auto-tuning in ssh/sshd for SFTP since we have a way to measure RTTs -- we don't have an easy way to determine max bandwidth (of local interfaces), but we can heuristically manage the SNDBUF/RCVBUF sizes and SSHv2 channel window sizes (basically: increase until the observed BDP stops growing). Nico --
