Connection caching?

[Dan Kegel]

Damien Miller wrote:
>>on the distcc mailing list, a thread about load balancing
>>got a bit out of hand, and we started thinking about
>>moving fsh-like connection caching into ssh itself
> 
> The SSH protocol already includes the necessary capabilities to
> implement this

Yes, we noticed.

> One you have established a SSH transport, you can fire off lots of
> sessions (command, shell or subsystem) which have independant
> lifespans. Our client only supports a single such session, but
> Our sshd already has this capability and I believe that the
> ssh.com windows client supports multiple connections against
> OpenSSH sshd.
> 
> To implement this in OpenSSH's ssh, I was thinking about adding
> an argument to get ssh to listen on a unix domain socket after
> authentication.
> 
> Additional sessions could be established by connecting to this
> socket, using SCM_RIGHTS messages to pass the std{in,out,err} fds
> to the connected ssh. It would probably be easiest to modify ssh
> to be the client, as it already does most of the buffering, etc.

Yep.  That would help in many situations (for instance, in using
ssh as a transport for remote gcc regression testing, which fires
off zillions of short jobs to a single remote system).

To use it with distcc would be a bit messier.  Let's say there
are 16 machines in the distcc cluster.   Do we really want the
user to have to fire off 16 ssh commands and leave them all
running in the background?   If so, what unix domain address would
each one listen on?
There are nasty limits on unix domain socket naming if you
want to be portable to all unix systems, so we might not
be able to put the hostname of the remote system into the socket address.

Would it be possible to pass a new hostname to that unix domain
socket, and have it fire up a new physical connection, too,
such that a single copy of ssh could support simultaneous connections
to all the machines in the distcc cluster?   That would simplify
the addressing question, and would make using this with a large
cluster a lot easier, too.
- Dan

-- 
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change