Connection caching?

[Damien Miller]

David Woodhouse wrote:

> On Mon, 2004-05-03 at 07:45 +1000, Damien Miller wrote:
> 
>>I don't much like the idea of a single ssh instance representing multiple 
>>client to server connections. It would add a fair bit of complexity to 
>>ssh for (IMO) little benefit.
> 
> Surely it shouldn't be much complexity? Doing it anywhere _but_ in
> ssh(1) will just lead to it being duplicated repeatedly, surely?

I think that my words were ambiguous: I don't think that a single ssh
process should represent multiple connections to *different* servers.

Does that address your concern?

> Doing it in SSH, we can add an option which instructs the client to
> leave a connection open and daemonize itself, and an option which
> instructs the client to look for the unix domain socket created by such
> a daemon.

That is exactly what I propose: start a ssh to a server, then use a
client-side listening socket to run multiple sessions to that server
over the transport.

> You also want to include the username, 

I don't think you would want to put the control files anywhere other
than a mode 0700 directory owned by the user who started the
connection. We enforce similar restrictions on keys and (in -current)
.ssh/config. Given this, I don't see a need for putting the username in
there.

> and possibly also the _local_ IP
> address used for the connection in question. Or you have to deal with
> dynamic IP addresses somehow -- perhaps by means of keepalive. Fsh
> screws that up, and it's a PITA.

ssh will terminate when the address changes, so what does this buy you?

We do app-level keepalives: {Client,Server}Alive{Count,Max}. We just
need to ensure that a terminating ssh cleans up its control socket
gracefully. Anything that wants to make use of this facility could
just do something like:

[ -s ~/.ssh/ctl-$host ] || ssh -nNfo ControlSock=~/.ssh/ctl-$host $host

I.e ensure that the socket is ready, or start a new connection.

-d