<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">Hi Keith,</span><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Brilliant, it looks like we're gonna be able to get this sussed out then.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">So, the licensing stuff. We're building mosh-client from source on a dedicated build server and then including that binary with our app to run as a subprocess. We've also included (as of this release) an About page in our Settings Menu which displays information and licenses of all open source projects used, including the GPL notice.</div>
<div style="font-family:arial,sans-serif;font-size:13px">Our application isn't open source as that would rather quickly make our in-app purchase worthless however, mosh and other open source dependent features are included within JuiceSSH's core functionality and will never require a purchase. Whilst we don't want or expect to ever make a huge sum of money through pro-pack purchases, we do have some hosting and test device costs we'd like to cover.</div>
<div style="font-family:arial,sans-serif;font-size:13px">If you feel that we're not meeting the requirements of mosh's license, we'll be happy to do our best to make changes to that end.</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">I think I understand what you mean by only allowing a restore to happen once from a serialised state. But just to check, if a session had been restored in a new process successfully, would we then be able to repeat the save state and resume later procedure?</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">The kill signal solution with the state printed stdout should definitely be workable. It'll take a bit of work to intercept the io streams before it reaches the terminal but it's certainly not impossible.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">A couple of ideas that come to mind with this functionality:</div><div style="font-family:arial,sans-serif;font-size:13px">
<ol><li style="margin-left:15px">JuiceSSH has a pro feature called CloudSync which keeps devices in sync with AES-256 encrypted backups. There's the potential to use this or NFC to add some "Resume on tablet" functionality.</li>
<li style="margin-left:15px">Is there anything server side that would prevent a state being reused more than once? For example, if a connection is made where the client's state is older than that of the last recorded client state, then the new client (in the older state) is denied updates.</li>
</ol><div>Thanks again,</div></div><div style="font-family:arial,sans-serif;font-size:13px">Tom</div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div style="color:rgb(136,136,136)"><font face="verdana, sans-serif" size="4"><br>
</font></div><div style="color:rgb(136,136,136)"><font face="verdana, sans-serif" size="4">Tom Maddox</font></div><div style="color:rgb(136,136,136)"><font size="1"><b>Co-founder, Sonelli Ltd</b></font></div><div style="color:rgb(136,136,136)">
<font size="1"><a href="mailto:tom@sonelli.com" style="color:rgb(17,85,204)" target="_blank">tom@sonelli.com</a> | <a href="https://sonelli.com/" style="color:rgb(17,85,204)" target="_blank">https://sonelli.com</a></font></div>
<div style="color:rgb(136,136,136)"><font face="verdana, sans-serif"><a href="https://play.google.com/store/apps/details?id=com.sonelli.juicessh" style="color:rgb(17,85,204)" target="_blank">JuiceSSH - Free SSH client for Android</a></font></div>
</div></div>
<br><br><div class="gmail_quote">On 4 August 2013 04:57, Keith Winstein <span dir="ltr"><<a href="mailto:keithw@mit.edu" target="_blank">keithw@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Tom,<br><br>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.<br><br>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.<br>
<br>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.<br>
<br>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?)<br><br>Also, what sort of timeframe are you looking at for your release?<br>
<br>Cheers,<br>Keith<br><br><div class="gmail_quote"><div><div class="h5">On Sat, Aug 3, 2013 at 1:34 PM, Tom Maddox <span dir="ltr"><<a href="mailto:tom@sonelli.com" target="_blank">tom@sonelli.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">Hi,</span><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">We're currently beta testing MOSH integration with our Android SSH client, JuiceSSH, of which the progress can be followed in our <a href="https://plus.google.com/u/0/communities/110428419162168502506" target="_blank">G+ community</a>.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">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.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">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.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">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.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">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.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">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.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">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!</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Thanks and regards,</div><div style="font-family:arial,sans-serif;font-size:13px">Tom</div><span><font color="#888888"><div>
<div dir="ltr">
<div style="color:rgb(136,136,136)"><font face="verdana, sans-serif" size="4"><br></font></div><div style="color:rgb(136,136,136)"><font face="verdana, sans-serif" size="4">Tom Maddox</font></div><div style="color:rgb(136,136,136)">
<font size="1"><b>Co-founder, Sonelli Ltd</b></font></div><div style="color:rgb(136,136,136)"><font size="1"><a href="mailto:tom@sonelli.com" style="color:rgb(17,85,204)" target="_blank">tom@sonelli.com</a> | <a href="https://sonelli.com/" style="color:rgb(17,85,204)" target="_blank">https://sonelli.com</a></font></div>
<div style="color:rgb(136,136,136)"><font face="verdana, sans-serif"><a href="https://play.google.com/store/apps/details?id=com.sonelli.juicessh" style="color:rgb(17,85,204)" target="_blank">JuiceSSH - Free SSH client for Android</a></font></div>
</div></div>
</font></span></div>
<br></div></div><div class="im">_______________________________________________<br>
mosh-devel mailing list<br>
<a href="mailto:mosh-devel@mit.edu" target="_blank">mosh-devel@mit.edu</a><br>
<a href="http://mailman.mit.edu/mailman/listinfo/mosh-devel" target="_blank">http://mailman.mit.edu/mailman/listinfo/mosh-devel</a><br>
<br></div></blockquote></div><br>
</blockquote></div><br></div>