Re: protecting against WiFi loss

[Eric S. Johansson]

address@hidden wrote:
> The connections you are trying to preserve are handled by ssh, and have 
> nothing to do with screen.  They require a constant connection, and 
> AFAIK cannot be put into suspended animation as you describe because 
> they require constant communication between the server and your laptop.  
> When the laptop goes to sleep, this communication is broken, and the 
> connection is dropped.  That's the way it's supposed to work.
>
> There may be tools that allow you to approximate this functionality, 
> like NX or autossh, though I don't really know anything about them, just 
> something to take a look at.  Maybe if you give a more detailed 
> description about what you're trying to do someone can provide some more 
> help.

I was probably too tired and didn't explain the problem properly.

yes, you are right that when a machine goes in to suspend mode, the link 
breaks as well as any communications over that link.  The problem is, 
when the connection breaks, my application goes poof.  If I use screen, 
my application stays running.  Unfortunately, all of the additional 
connections such as X11 forwarding goes away.

If I use screen, and don't worry about the additional connections, I 
have some problems I don't know how to resolve.  For example, how do I 
connect only to screen sessions that were originally connected to 
terminals?  For example, I have been known once in awhile to associate a 
screen session to a long-running process so I can check in on it from 
time to time.  obviously, I don't want to connect to this screen session 
except when I explicitly request it.

How do I start a single screen automatically when I login and have that 
screen terminate when I manually log out but not when the connection breaks?

In last, how do I disable any interpretation of characters going through 
screen and so I can have a completely transparent pipe to my 
application.  It seems that no matter what remapping I use, it always 
gets in the way.  it definitely gets in the way if you have a screen 
connected to a screen (see long-term running process example above, and 
no, I don't run multiple sessions in a single screen.  I want one 
terminal window here connected to one process there)

I've had problems with resizing terminal windows communicating the 
resize to screen and through screen so that the application can run with 
more local machine screen real estate.

The more I think about the problem, the more it seems like I want a 
connection proxy that can cooperate with an ssh client to know about 
things like Port forwarding but can also survived disconnect and have a 
way to reconnect to the user's terminal.  It may also be possible to do 
this almost completely UNIX side.

Unfortunately, for autossh and the like, I'm stuck on Windows.  I'm 
stuck on Windows because I'm handicapped and use speech recognition 
(another reason why the screen escape characters suck, it's really hard 
to speak them consistently)  NX, vnc, and the like also suck because 
they consume enough CPU time to make speech-recognition slow and 
unreliable.  (Yes, this topic puts me in a foul mood because I've been 
living with it for 10 years and it is not getting any better because by 
the time developers understand the problem, they are injured themselves 
can't help with building a solution.)

Thank you for helping me focus to request a little more.  It's beginning 
to look like I will need to find some hands to help me build the solution.