> > > > My question:  Should ssh be able to survive that?  My thought is that it
> > > > can't, because my IP number necessarily changed.  Unless ssh is a lot
> > > > brighter than I give it credit for...  (^&
> > >
> > > A TCP connection can't survive if the IP address changed. ssh isn't
> > > designed to restart a tcp connection for the sme session.
> >
> > I know that TCP can't handle it.  That's why this seems like a ``good
> > thing'' for ssh to be able to recover from.  I'd hoped that it was a
> > feature that was built into ssh.  Alas, from what you say, ssh doesn't
> > provide recovery for this, either.
>
> part of the problem with applications tolerating NAT is that DNS names
> are sometimes ambiguous in practice - either because multiple hosts are
> associated with a DNS name, or because the DNS name is tied to the IP

I hadn't considered the effect that NAT would have on this.


> address that changed.  so attempting to 'recover' a connection by
> re-connecting to another IP address associated with the DNS name you
> used last time doesn't necessarily get you the same host you were
> talking to before.

math.rice.edu is pretty fixed, no matter what happens to my home machiens.
(^&  Unless they do a major operation on the server, it *will* be the same
host, every time.


> admittedly this would often work for the specific example of ssh,
> and ssh already has the mechanisms necessary to verify that it's
> talking to the same host as before.

Unless ssh stores the username/password pair, this may not be sufficient
(who's to say that I'm the same *user*?).  Still, I wouldn't mind having
to type a password to verify myself before resuming a broken connection.

I'm not sure that I care that much about validating that it's the same
machine.  If the communications channel between the two hosts has gone
dead for, say, 30 seconds, and a new connection (possibly from a different
address) says, "Hey, I'm really user `rauch', trying to revive my old ssh
connection; send all traffic to this channel now", why isn't that enough?

Of course, the new channel would have to prove itself by password.  And
perhaps some last attempt to revive the "dead" connection should be made
before even considering a password challenge/etc. from the new one.

But, all that said...  Why not?  It looks to me like it'd work.


> another part of the problem is that you want the recovery to happen
> without losing any data.  when a NAT breaks a TCP connection then
> the application has no idea how much of the data that has been sent

For a shell process, this is not a problem.  Most screen-interactive
programs support ^L to refresh/repaint.  Line-oriented programs usually
have some kind of history feature, and/or you can live with some lost
events.  (More easily than with a broken connection, anyway...(^&)

Still, for shell processes I could just use GNU screen.  So my attention
is focused on X.  I'm not sure how the X protocol would complicate life
(since I've never gone any lower than Xlib programming, and even then have
only lightly brushed it).  Maybe making X function acceptably through a
reconnect (without buffering X protocol commands and replies) wouldn't
work.


> broken connections not only requires explicit acks at the application
> level, it also requires that the sending application buffer all data
> that is sent to its peer until it gets explicit acks for that data.
> it also has to implement duplicate message suppression at a layer
> above TCP.

Why would it have to deal with duplicate messages?  If the TCP connection
was broken and a new one was established, nothing more will come from the
old connection, correct?  (Or the old connection could be discarded
completely.)  Since ssh runs over TCP, TCP itself should ensure that the
new connection contains no duplicates.

What am I missing?  Where would duplicates come from?

Or did you have in mind that such a revised protocol would no longer use
TCP, and would then have to assume all of the duties normally provided by
TCP?


  ``I probably don't know what I'm talking about.'' --rauch@math.rice.edu