Add "Always Keep This Host Connected" checkbox option to host settings about connectbot HOT 32 CLOSED

agreed this would be a great feature.  i think we only might allow this with
publickeys, because saving any password used in memory is risky.

Agreed that a passworded session should be required to re-enter password...

For port-tunneling (as for email checking/sending), this would be very useful.

Was there ever progress on this?  Some means to keep connections open 
(automatic 
reconnect on connection close) would be extremely useful for a range of 
situations.  
Thanks.

Still would *love* this feature...

W

Issue 109 has been merged into this issue.

I've hacked up a patch for this. It's currently far too nasty to post, but 
hopefully
I can clean it up shortly and post it.

It works by having the TerminalBridge go ahead and die on disconnection, and 
then
having the TerminalManager restart the connection. I had to add some 
synchronization
in TerminalBridge to prevent it from disconnecting twice in some cases due to a 
race
condition. I also had to add a parameter to onDisconnect indicating whether the
disconnection was user-requested, so that if the user presses 'disconnect' we 
can
avoid restarting the session.

I thought about handling the reconnecting in TerminalBridge; but it has tons of 
state
I'd have to reset, so letting TerminalManager recreate it seems much easier.

The main issue with this that I can't trivially fix is that, if the user has the
session open when the disconnection occurs, the console stops updating -- the 
session
reconnects but the user has to exit and reenter the console to see it. I don't
immediately know how to fix this.

(Of course this is all predicated on an official patch not beating me to the 
punch,
but I figured I'd put this out there.)

Sounds like great work.  I look forward to seeing this patch as soon as 
possible -- 
it will certainly be extremely handy for me.  As for the console issue ...

Since any open ssh session at the ssh server is likely going to be killed 
anyway 
when the connection disconnects, why not just blow away the current console at 
reconnect time and establish the new connection using an entirely new console 
instance (ideally with the same font size, etc. setting that was in force for 
the 
original console at the time of disconnect).

Or am I missing some important aspect of this problem?

Thanks!

Lauren4321, until this patch is applied please note that the "screen" manager 
with the same name is very 
effective solution to prevent any major problems with lost ssh connections. (As 
long as you are just using 
shell and not tunnels or x11.) Screen comes installed on most *nix system.

-Charles

Right.  Though in my particular case it isn't particularly useful since I don't 
really want ssh sessions hanging around indefinitely if I'm disconnected -- 
when the 
connection is reestablished I'm going to end up back where I should be anyway 
virtually all the time due to my .bashrc setup, etc.  What's more important 
from my 
standpoint is that the connectbot console not hang at auto-reconnect -- if 
accomplishing that means a fresh console instance for now that will work for me 
at 
least.

@lauren4321: It doesn't hang as far as the server's concerned -- all that hangs 
is
the display in connectbot, if you happen to have it open when the reconnect 
occurs
(and only until you close and open it again). Since my use case for this is to 
leave
a connection open in the background, this doesn't affect me, but I'd still like 
to
fix it. My plan is to blow away and replace the console -- but I've only been 
hacking
on ConnectBot for about a week now, so I'm still figuring out how to do that. 
:-) I
am in fact using screen as described by ctempleton3, along with a "post-login
automation" command to resume the screen.

Patch attached, with deficiency as already described. :-)

ACK, WARNING WARNING before you apply that patch!!!!

It will upgrade your database to a version which includes a new field for the
"persistent connection" flag! In the event that the maintainers don't like my 
patch,
or choose to upgrade the database differently, you will have an incompatible 
database
and will have to nuke it before going back to the official build!!!!

So PLEASE don't apply this patch without backing up your database if you care! 
(I
believe performing such a backup requires root, unfortunately. :-\)

Which database are we talking about, local to connectbot or more global?  If 
the 
former, no big deal, if the latter, bad news (and in such a case, perhaps 
maintaining that flag in a standalone file instead for now would be safer).

As for the console, I'm still not entirely clear on the issue.  Are you saying 
that 
the console hangs if it is the currently selected foreground console, 
regardless of 
whether or not it is being currently displayed?  In my situation, I usually 
only use 
one console, but it's important that I get audible notifications from it when 
events 
occur, regardless of whether I'm running some other program using the screen at 
the 
same time or not.

@lauren4321: Sorry, just ConnectBot's host database. Nothing global.

As to the console: Only the display hangs. If the console is not being 
displayed,
nothing hangs; if it's being displayed, it continues running in the background 
as
though not displayed, but the display ceases updating. So it's purely a 
cosmetic issue.

When you speak of "audible notifications", do you have a patch to let ConnectBot
issue those? I've got it vibrating on ^G... (and this is an example of 
something that
continues to run even if the display is hung, since it's happening in the
TerminalBridge which runs under the TerminalManager serivce.)

OK, if ^G handling continues in either case, that solves my main problem for 
now.  
Yes, I use a simple patch (originally from someone else in this group) to 
generate 
a "new mail" audible warning from Mutt via ^G.  I also have another patch that 
generates a different audible warning when connections are lost (which will 
probably 
become superfluous with auto-reconnect).  I've actually got Mutt quite 
customized 
for the G1 now, and it's extremely usable, with macros set up for one-handed 
access 
to basic functions via the trackball, etc.

Can you clarify the database issue that was mentioned earlier?  Thanks.

I missed your earlier response re the database being local.
Thanks.

Aren't there host_prefs.xml changes, etc. that are missing from the patch?  
Thanks.

Yikes, you are correct. host_prefs.xml is the only bit I was missing. (I did my 
diff
of /src/ directories to keep the binaries out of it, and forgot about /res/.) 
Better
patch, I hope:

(I have been running this for a day or so now, combined with a ^G-vibrate 
patch. It
works quite well in the presence of a solid connection which sometimes cuts 
out. It
doesn't work so well when the connection is always very weak but never actually 
cuts
out completely; but TCP itself behaves badly under such circumstances, so I 
don't
blame ConnectBot.)

Can you please post your ^G vibrate patch?  I'd like to compare it with the 
audio 
notification patch I'm using and probably make it an option.  Thanks.

I've tested the reconnect code a bit.  The results are a little uneven.  Most 
of the 
time, if the phone is in "standby" (screen blanked from pressing red button), 
the 
connection doesn't retry after being broken -- until the phone comes out of 
standby.  Occasionally, it *does* retry even on standby.

Notably, ^G bells will always function when sent out through the ssh connection 
to 
the phone, even in standby -- so presumably there's a way to catch this 
situation.  
I'm still running more tests ...

Additional note.  Given enough time (e.g. 8 to 10 minutes) it appears that more 
reconnects do occur in standby.  There's a pattern to this but I don't have 
enough 
data points yet to be sure what's going on.

You guys should take discussions to the mailing list:

http://groups.google.com/group/connectbot-users

Looks like there's a likely bug/interaction under Android 1.5.  I just ported 
over 
the autoreconnect code to the latest revision, along with the patch (manually 
done) 
for sound on ^G.  Both work.  

However, if a ^G event occurs while the program is in that "frozen display" 
state 
discussed above (after an autoreconnect), the program now reliably crashes.  
Previously, ^G would successfully play a bell or vibrate, or whatever was set 
up.

But those events now appear to be fatal.  If the display has been "unfrozen" by 
other activity (a quick flip to the home screen for example), the ^G events 
will 
then play fine -- the crashes only occur if the events happen while the screen 
is 
still frozen.

I haven't tried digging into the reasons why yet.

Here's a debug log of the crash:

05-31 03:32:37.105: DEBUG/class org.connectbot.service.TerminalManager(723): 
attempting session reconnection in the TerminalManager
05-31 03:32:54.536: WARN/dalvikvm(723): threadid=25: thread exiting with 
uncaught 
exception (group=0x4000fe70)
05-31 03:32:54.546: ERROR/AndroidRuntime(723): Uncaught handler: thread 
Thread-43 
exiting due to uncaught exception
05-31 03:32:54.556: ERROR/AndroidRuntime(723): java.lang.NullPointerException
05-31 03:32:54.556: ERROR/AndroidRuntime(723):     at 
org.connectbot.service.TerminalBridge$2.beep(TerminalBridge.java:500)
05-31 03:32:54.556: ERROR/AndroidRuntime(723):     at 
de.mud.terminal.vt320.putChar
(vt320.java:1544)
05-31 03:32:54.556: ERROR/AndroidRuntime(723):     at 
de.mud.terminal.vt320.putString
(vt320.java:108)
05-31 03:32:54.556: ERROR/AndroidRuntime(723):     at 
org.connectbot.service.TerminalBridge$Relay.run(TerminalBridge.java:299)
05-31 03:32:54.556: ERROR/AndroidRuntime(723):     at java.lang.Thread.run
(Thread.java:1058)
05-31 03:32:54.576: INFO/Process(582): Sending signal. PID: 723 SIG: 3
05-31 03:32:54.586: INFO/dalvikvm(723): threadid=7: reacting to signal 3
05-31 03:32:54.746: INFO/dalvikvm(723): Wrote stack trace to 
'/data/anr/traces.txt'

I don't have the autoconnect patch handy so I didn't try to reproduce this but 
try
putting an if (parent != null) check around it the parent.beep() call. 

Thanks. Just tested.  Yes, this stops the crash.  It also prevents any 
notifications 
from sounding while the screen is in the autoreconnect "frozen" state, which I 
*thought* did sound under pre-1.5 in that same condition -- didn't it?

Issue 161 has been merged into this issue.

I put this in r356. Let me know how it works.

Thanks so much for this!  Did a bit of testing.  Autoreconnect seemed to occur 
almost every time (I saw one instance of hanging until more local terminal 
activity, 
haven't tried to replicate really yet).  There may be a problem with the screen 
dimensions on reconnect -- my curses-based program's screen has wrong v and h 
dimensions until a size change is forced manually, on every reconnect.  Haven't
really tested this much either, but something seems odd in this aspect.  Thanks 
again!

Was that with SSH transport or another? I'll check the resize issue.

Excellent! I'm thrilled to hear this is in, so I can switch away from my 
somewhat-
crashy patch. :-) (I'm curious if you are using my code at all; I've been using 
it 
since I posted the patch, and as I say it's been crashy, though useful, but I 
don't 
know if it was close enough to good to be useful.)

Right, the resize issue was occurring in SSH mode.  I have not tested other 
modes 
for this at all, however.  It appears that the terminal resets to some default 
dimensions on reconnect rather than maintain the dimensions in place prior to 
the 
disconnect.  In my case, that confuses the curses-based program at the other 
end 
until I manually change sizes again, at which point they usually sync up and 
redraw.

I want to add inline here how incredibly useful connectbot has become over such 
a 
short period of time.  It's by far my most used G1 app.  Really the only 
missing 
important "major" feature right now from my standpoint is clickable links, and 
I 
realize that's a tough one in the current model.