[mosh-devel] JuiceSSH STPClient Resuming

[Keith Winstein]

Hi Tom,

Thanks for getting in touch. We can work with you to serialize the state of
an STMClient object and restore it later. We are eager to see an Android
Mosh client in the Play Store.

The major major constraint here is that you can only restore from a
serialized state *once*. We will want mosh-client to erase the serialized
state before using it to make sure it can't be reused. The reason is that
if you reuse a crypto sequence number (the nonce), that blows everything.

How would you like to communicate with mosh-client that you want it to quit
and dump state? You could just send us a SIGUSR1 or something and we could
write it to stdout bracketed with something like BEGIN MOSH SAVED STATE if
that works for you. And then if you give us a filename on startup (that we
can erase), that would work fine to restore.

I should ask -- are you running mosh-client as a separate binary or are you
linking against it? (If linking against it, just to check, is your app
under the GPL too?)

Also, what sort of timeframe are you looking at for your release?

Cheers,
Keith

On Sat, Aug 3, 2013 at 1:34 PM, Tom Maddox <tom at sonelli.com> wrote:

> Hi,
>
> We're currently beta testing MOSH integration with our Android SSH client,
> JuiceSSH, of which the progress can be followed in our G+ community<https://plus.google.com/u/0/communities/110428419162168502506>
> .
>
> One issue that has been raised so far is battery usage. Currently when
> JuiceSSH has any active connections, there is a service running which holds
> a device wake lock and polls the connections for failures. Seeing as Mosh
> sessions should always be resumable, and as Keith pointed out, this
> shouldn't be necessary in the case of Mosh.
>
> Keith implied that he may be able to help us save the state of a
> mosh-client process, allowing for it to be resumed in the future.
>
> I've planned the majority of how to exclude Mosh sessions from wake locks
> and connection polling, and I'm confident that we'll be able to catch the
> point that the state should be saved and then finally I know how we could
> implement an "if-process-not-running-attempt-resume"-esque session.
>
> But the bit I'm not sure about is how to get the state, what form it will
> be in, and then how to reuse it.
>
> Having looked through the research paper and checking out the
> presentation, it would appear that this functionality is not yet in place.
> If so, and this functionality is new, then one solution I can think of
> would be the ability to run "mosh-client <IP> <Port> --resume-from-state
> [<State-Related-Params>|<State-File>]" to resume the process and perhaps a
> certain kill signal could result in mosh-client printing it's state just
> before it finishes.
>
> Any thoughts or help would be really appreciated. We're both very excited
> here about how convenient and nice this tool will be. As a couple of
> SysAdmins that wrote JuiceSSH mostly during our commutes on trains, we
> certainly appreciate the benefits!
>
> Thanks and regards,
> Tom
>
> Tom Maddox
> *Co-founder, Sonelli Ltd*
> tom at sonelli.com | https://sonelli.com
> JuiceSSH - Free SSH client for Android<https://play.google.com/store/apps/details?id=com.sonelli.juicessh>
>
> _______________________________________________
> mosh-devel mailing list
> mosh-devel at mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130803/7c6c6eb0/attachment.html