On Thu, Apr 15, 2004 at 09:46:18AM +0200, Tom Ivar Helbekkmo wrote:
> Ivan Popov <pin_at_medic.chalmers.se> writes:
> 
> > reconfigured. You see, ssh _could_ cache the user's password and try
> > to reestablish a connection once it breaks...
> 
> Yeah, but to be useful, it would have to actually re-establish the
> same connection through a different path, so that the same connection
> now had a new endpoint.  In other words, a general TCP connection
> migration facility.  Incredibly useful, but pie-in-the-sky for now.

It depends on ssh protocol and implementation.
ssh is connection-oriented, a session lives as long as the tcp connection.
It could "reestablich the same connection" with reconnection support
in the protocol but not otherwise.

I can not imagine "tcp connection migration" :)
as a tcp connection is _defined_ by two pairs of addresses and ports.
You need some different context to persist to be able to name it "migration"
but not just "another connection".
As such context is application-related, it has to be implemented on the
application level.

> > It cannot go "unnoticed" by Venus, you will become disconnected and
> > eventually reconnect again.
> 
> Well, yes, but it could automatically reconnect through the new
> network path the moment it noticed that the old interface/address
> combination was defective, right?

Venus tries to keep the connection for some time while servers do not answer.
The same is for the server when it notices that a client has gone.
At some time some of them becomes tired and drops the connection context
on the floor, then it is over.
Unfortunately, reconnection causes revalidation of cached objects, it is
a payoff for the lost state information...

The main difference between stable and volatile ip numbers is that we'd need
a connection context which would be independent of the actual ip information,
and some heuristics for trying to keep a connection, say retrying different
local and foreign addresses, with the same connection context.
Unfortunately, it looks like a bigger change. Anyway, I suspect it will
be done, sooner or later.

Essentially, Coda does not have to be transport-dependent - but it is still
rather hard bound to ip. In a sence it is bound to dns as well, as there is
no other global distributed directory service to rely on...

Best regards,
--
Ivan