Mosh: Modernizing SSH With IP Roaming, Instant Local Echo 158
An anonymous reader writes "Launched in 1995, SSH quickly became the king of network login tools, supplanting the old insecure mainstays TELNET and RLOGIN. But 17 years later, a group of MIT hackers have come out with "mosh", which claims to modernize the most annoying parts of SSH. Mosh keeps its connection alive when clients roam among WiFi networks or switch to 3G, and gives instant feedback on typing (and deleting). No more annoying network lag on typing, the MIT boffins say, citing Bufferbloat, which has been increasing latencies."
The folks involved have a pre-press research paper with the gritty details (to be presented at USENIX later this year). Mosh itself is not particularly exciting; the new State Synchronization Protocol it is based upon might be: "This is accomplished using a new protocol called the State Synchronization Protocol, for which Mosh is the first application. SSP runs over UDP, synchronizing the state of any object from one host to another. Datagrams are encrypted and authenticated using AES-128 in OCB mode. While SSP takes care of the networking protocol, it is the implementation of the object being synchronized that defines the ultimate semantics of the protocol."
First they invented telnet, which had... (Score:5, Insightful)
And 15 years later, LOCAL_ECHO is back in mosh!
Younger coders usually think they know best.. (Score:3)
Then they discover there was usually a good reason for something being done the way it was in the past. Eg local echo was very useful for line buffered programs such as MUDs and chat servers or even talking to SENDMAIL or an FTP server directly. It was easier to write the server to cope with just line by line rather than character by character and it used up less network resources in the process.
Re: (Score:2)
Re: (Score:2)
Hmmm.. I think you are fibbing.. the next step up from 110 baud was 300... and I surely date myself with that knowledge. I miss my LA-120.
Re: (Score:2)
When I had my Atari 800, I got an MPP-100C modem. It was a 300, but could go to 450. So if I dialed into a BBS that had a 1200 baud line, WOOHOO!
Re: (Score:3)
Here is a data sheet for such a modem [datasheetarchive.com]
Re: (Score:2)
My first computer experience (1972) was at 110 baud, banging away
on an ASR-33 Teletype connected via leased line to a DEC PDP-8 running Dartmouth Basic.
I'd get up and run a lap around the building for fresh air while printing
a program listing. Data rate in/out was 10 CPS (Characters Per Second).
I recall proudly showing my dad the program listing at home, unrolled on the living room floor at about 10 or 12 feet long...
Re: (Score:2)
Until about 1996 I regularly used a Minitel (v23, http://en.wikipedia.org/wiki/Minitel [wikipedia.org]) 75 bps upload, no chance of it keeping up even with a crappy keyboard!
Re:First they invented telnet, which had... (Score:5, Interesting)
.. a negotiable LOCAL_ECHO mode. Then they invented ssh, and left away that LOCAL_ECHO and linebuffered flags, considered to be archaic. And 15 years later, LOCAL_ECHO is back in mosh!
Right. Breaking local echo in Telnet was a Berkeley misfeature. It was in 3COM's UNET, which predated Berkley networking in UNIX. (Berkeley did not introduce networking in UNIX. Theirs was the third or fourth implementation, after ones from BBN, 3COM, and Phil Karn.) With UNET, circa 1983, Telnet had local echo until you used something like VI or the RAND full screen editor, at which point the server noticed the stty call which switched to "raw mode" and switched to remote echo.
Seamless transition from local echo to remote echo is even older. It was in Tymnet [rogerdmoore.ca], which used markers called a "red ball" and a "green ball" to do the switch seamlessly.
Red ball, Green ball (Score:2)
Pass on the local echo please! (Score:5, Insightful)
and gives instant feedback on typing (and deleting).
That sounds like a step backwards to me. Any utility in that is lost when something doesn’t sync up properly. When I hit a key, I want to know it has been sent and received and see the result.. not see the result as my shell predicts it. Maybe I’m just having local echo flashbacks from past telnet experiences.
Everything else sounds really neat though. I don’t jump wifi often enough for re-connecting and re-attaching to screen to be a big deal.. but I can see the utility for those who do.
Re: (Score:1)
It's not like you aren't used to passing a bunch of obscure flags to Linux commands anyway. I'm sure there will be one for this, as well as a ssh_config option.
Re:Pass on the local echo please! (Score:5, Informative)
From their website:
Disable instant echo
$ mosh --predict=never niennunb
The -n switch is a synonym. By contrast, passing --predict=always or -a will enable instant local echo even on low-delay links.
Sounds like it tries to be smart about this, but not so smart as to not allow a human to force things the way he wants them.
Re: (Score:2)
Hmm, I missed that bit. I assumed there would be a feature to disable it, but didn't realize it would only come on in low latency ..
Re:Pass on the local echo please! (Score:5, Informative)
According to their website, locally echoed but not yet synced input is visually distinct from synced content, so you'll always know what has been sent and what hasn't.
Re:Pass on the local echo please! (Score:5, Informative)
I've been using it for a few days now, and I find the local echo to be quite a useful feature. Many of the machines I remotely use are on different continents, and waiting for my keypress to make a round trip can be frustrating at times.
Mosh also makes it clear which characters have been successfully transmitted by underlining those that are still finding their way through the tubes... i've never been unsure what has or has not been received.
After a few days of using mosh, I don't see myself going back to plain old ssh anytime soon.
Re: (Score:2)
Sounds like a great solution. Responsiveness is critical for user interaction, therefore, local echo is vital for high latency links. Knowing that the remote end has received the same thing you see locally (and if it's performing character-by-character filtering, seeing those results) is also important. Local echo, with remote echo verification.
Maybe not so good with completion (Score:3, Insightful)
Modern shells have completion, and mosh is not going to predict that.
It seems to me that for my typical usage it is going to have limited utility - I'm either in a shell where I'm leaning heavily on the tab for completion, or in vi where it would need to secondguess what vi is going to display.
Re: (Score:2)
IIRC in the original telnet protocol the list of keys that prompt synchronization with the server is negotiable. Normally that would be carriage return, and going to a full-screen editor would disable local echo, but adding tab to the list when in a shell should be trivial.
Re: (Score:3)
That sounds like a step backwards to me. Any utility in that is lost when something doesnâ(TM)t sync up properly. When I hit a key, I want to know it has been sent and received and see the result.. not see the result as my shell predicts it.
Easy to say until you are (attempting to) type in a longish shell command into a server across an overloaded Internet connection. In that situation, you have two choices: either wait 1 second after each character, to make sure you typed it correctly, or blindly type a bunch of characters at once and hope you didn't make any typos. And if you did make a typo, then you're really in the sh*t, because now you have to figure out how many characters you actually since then, and press backspace EXACTLY that num
Instant local echo (Score:1)
I stopped reading after this (Score:1)
"To bootstrap an SSP connection, the user rst logs in to the remote host using conventional means, such as SSH or Kerberos."
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
And many (most?) SSH clients support auto-reconnect on short network drops. And many even support reconnect on IP change (like when switching wireless networks or to 3G). And you can even configure your tmux (way better than screen) session to connect on login.
Thus, many SSH clients already do everything that MOSH does, but without having to install any new software anywhere.
Re: (Score:3)
And many (most?) SSH clients support auto-reconnect on short network drops.
It's not even a case of reconnect. A TCP connection lasts forever or until one side says "stop"; all the client has to do is *not* explicitly time out after N seconds. Misconfigured NAT devices tend to fuck this up though; one of many reasons NAT is evil.
Re: (Score:2)
This. My guess is fixups for automatically opening pinholes for Cisco gear will be a long time coming for this new protocol. Really this needs to be integrated into the SSH server and run on the SSH port to be useful in a modern enterprise environment.
Re: (Score:2)
So that means it's just like GNU Screen? ctrl+a d on one connection, hop wifi, ssh and screen -x. wow. Really?
Except the feature will be there even if you don't want it, I guess. Who cleans up the dead sessions, I wonder? It's already a problem with screen in some setups I've seen; people create sessions and then forget about them.
(Screen or similar software. I don't care what's the latest and greatest is; we're discussing the general feature of attached/detached terminal sessions.)
Re: (Score:2)
Yes, until I can figure out how to get it to stop ringing the bell when it starts and sending ^? instead of ^H for backspace, I'm still using screen.
Re: (Score:2)
Re: (Score:3)
Tmux's biggest claim is one of idealogy (BSD vs GPL) rather than any real technical merit.
Actually, tmux defaults at least are nice. When I 'tmux a' to share a session with someone else, our multi-window view is synced. Fit-to-terminal is a bit more sane too.
Screen developer/advocates really need to provide a guide on how to make screen behave like tmux default, if possible. Ctrl-A default bind is annoying as anything too.
Re: (Score:3)
Ctrl-A default bind is annoying as anything too.
Yeah, always had issues with that. I always set to CTRL-G, since the only thing I ever use that key for is bailing out of thinkos in emacs, and double-pumping that in non-screen mode is pretty harmless.
Plus, being an alarm key, it's more semantically correct.
Re: (Score:2)
"To bootstrap an SSP connection, the user rst logs in to the remote host using conventional means, such as SSH or Kerberos."
I stopped reading where it said they use UDP. People who say "I can outperform TCP" are almost always wrong, and I'm quite fed up with badly behaved UDP-based protocols. Citing the "bufferbloat" theory is also a bad sign, but that may be just a misleading summary.
Obsolete within five years (Score:3, Interesting)
While neat for those who are currently in areas with spotty wireless coverage it is a neat idea but for most users I don't think it's that much of an issue, even at the moment.
Fast forward five years and I just don't see this software being all that useful. Sure, there's always gonna be that handful of people who will scream that this is extremely useful because they're always hopping between wifi hotspots but most users are using 3G/4G when they're on the move and coverage for those is already "good enough" in most civilized places and steadily improving. I've taken 5+ hour train trips several times and only had ssh connections drop once or twice on those trips (due to spotty coverage in what would quality as the middle of nowhere in northern Sweden).
This is like "solving" the IPv4 address exhaustion problem with NAT, it's a neat workaround but doesn't actually solve the problem.
Re: (Score:2)
Satellite links, network congestion/delays, and other sources of high latency aren't going to magically disappear in 5 years, nor 10, 15, or 20 years. Until you can bypass the speed of light (in x transmission medium) as the limiting factor, this is useful.
Re: (Score:3)
Fast forward five years and I just don't see this software being all that useful. Sure, there's always gonna be that handful of people who will scream that this is extremely useful because they're always hopping between wifi hotspots but most users are using 3G/4G when they're on the move
Dunno about 4G, but 3G has enough latency to make ssh annoying, so Mosh would definitely be an improvement.
Re: (Score:3)
I just started using it (after seeing this article) to connect from my laptop which I suspend and carry in my backpack from work to home. Opened the lid, and the session is still seemingly intact after the few seconds it takes to find my home wifi.
No 4G connection in the world is gonna help a device that's effectively turned off.
I don't think this is a very unusual use case.
Re: (Score:2)
Re: (Score:2)
The "problem" with screen is that it requires manual intervention to resume. FWIW I've been using screen for this for the past ten years or so (well, tmux the last one or two...), but it's still annoying to have to reconnect and attach. mosh handles the reconnection transparently.
Re: (Score:2)
Roaming is not needed in mom's basement. (Score:3)
I see the need for this all the time. It's a commonplace in large enterprises like hospitals, factories, and financial services corporations.
Example: I'm working on my hospital laptop. I get called urgently to do something elsewhere in the hospital so somebody won't die right now. I grab the lappie and run, then when I get to the theatre I plug into the malfing imager and fix it. Meanwhile all my SSH connections died because I crossed three wireless boundaries at high speed.
Example 2: I'm on the line
Re:Obsolete within five years (Score:4, Insightful)
Re: (Score:2)
I work with tele-operated robots, and I must say this is an amazingly useful feature. The robots can establish a connection with either WiFi or 3G, and are meant to navigate in indoor environments. With WiFi, you can go a short distance before losing signal. With 3G, you can go a short distance before losing signal.
People with laptops or mobiles seldom notice the dead zones - they don't suddenly stop walking whenever they hit one.
Re: (Score:3)
This is like "solving" the IPv4 address exhaustion problem with NAT, it's a neat workaround but doesn't actually solve the problem.
I think you're not focusing on what the actual "problem" is. NAT really is a bandaid solution for a lack of IP addresses. NAT does solve the issue of multiple devices sharing an common WAN address.
Mosh addresses the issues of connections essentially being treated as static routes no more no less. The problem is the proliferation of different protocols and networks and devices which attempt to seemlessly hop between them to remain in a coverage area. While the hopping bit works quite well (as soon as I am ne
Re: (Score:2)
Not all the world has 4G. Heck, my mom live in a 300k population city (and one of the largest in this country), and there's not even 3G coverage there.
I've only one or twice picked up 3G coverage myself as well.
While I agree it 10 years this will be useless, it *is* usefull now.
Re: (Score:2)
you manage to concoct an edge case
Sorry, this is about 3G/4G, not EDGE.
how often do you ssh while in a moving car
As the passenger, of course. Only fools drive and text *wink* wink*.
that's going in and out of buildings?
Parking garages. Tunnels. Toll plazas. Petrol Stations. Or just between two tall buildings blocking out the signal.
Re: (Score:2)
And people still don't know how to use authorized_keys? WTF?
Re: (Score:2)
As the passenger, of course. Only fools drive and text *wink* wink*.
Walk and text and you might get eaten by a grue. Or at least by a bear: http://www.youtube.com/watch?v=WmhvdtX72eQ [youtube.com]
Re: (Score:2)
Wow you're dull and unimaginative. Imagine a cell phone constantly keeping in touch, and WiFi is faster than cell.
Imagine any number of things which are unimaginable. Stretch that brain!
Re: (Score:2)
OCB Mode is Toxic. (Score:5, Interesting)
We tried to put OCB mode in 802.11i. So IBM sent a guy to explain the 'licensing terms' for their patents on OCB mode. The next vote in 802.11i after that presentation was to replace OCB mode with CCM.
Until the patents expire or are freely licensed, OCB mode should be considered off limits for free and open projects.
Re: (Score:2, Informative)
according to Wikipedia: [wikipedia.org]
Re:OCB Mode is Toxic. (Score:5, Informative)
The patents are freely licensed for any GPL software; see link for details.
http://www.cs.ucdavis.edu/~rogaway/ocb/offer.htm [ucdavis.edu]
Mosh appears to be GPL:
https://github.com/keithw/mosh/blob/master/COPYING [github.com]
Re: (Score:3)
It would be an interesting battle. I read the Rogaway original paper years ago and he was granting free use to anything GPL licensed. For a more modern view you can also see"
http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm [ucdavis.edu]
I've looked into MOSH recently, and it is GPL. The battle would be, does mosh live under Rogaway's OCB patents which makes it free, or IBMs patents, which makes it unclear... From a "money is justice" perspective, I donno if ucdavis would win against IBM, but they'd have better odds
Other improvements ? (Score:5, Interesting)
IP roaming looks nice & ought to be secure with the right steps (no reply from old IP:port, correct cryto negotiation with new IP:port).
But LOCAL ECHO is a big problem -- applications have to be aware of it. On CLI, many keystrokes are commands, not text to be entered. On vi in command-mode, G goes to the last line.
Personally, a bigger thing is traffic reduction, particularly keystoke combining. Nagel's algorithm is a start, but I've modded ssh to delay and buffer likely-text keystrokes for a short time (400ms) while letting likely commands through immediately to retain responsiveness. The delays aren't irksome, and I reduce outbound traffic by ~80%.
Re: (Score:2)
Firewalls (Score:5, Insightful)
You open a SSH connection (client->server:22). This port is allowed on the firewall, it lets you through. But then the server decides to listen on UDP:(random port) and tells the client, back through the (encrypted) initial connection, which UDP port to contact. So you initiate a SSP UDP session on that port. How does the firewall knows it should let you through? Since the port number is communicated on an encrypted session, it doesn't have access to that information. So how does this work in a secure environment? The paper doesn't mention any mean for the server to communicate with the network which port its listening on.
Re: (Score:3)
Welcome to Yet Another Protocol Devised By Academics Who Have Not Been Near a Real Network in Twenty Years, If Ever.
Or YAPDBAWHNBNARNITYIE for short.
Re: (Score:2)
no it is not. security is made of layers.
you let UDP out (and actually for mosh you need UDP in, because unlike you, I tried), and anyone can use this to get a remote shell among other things.
udp in makes this easier than that of course
but hey that ok, lets remove all firewalls, AC said its better.
Re: (Score:3)
You open a SSH connection (client->server:22). This port is allowed on the firewall, it lets you through. But then the server decides to listen on UDP:(random port) and tells the client, back through the (encrypted) initial connection, which UDP port to contact. So you initiate a SSP UDP session on that port. How does the firewall knows it should let you through? Since the port number is communicated on an encrypted session, it doesn't have access to that information. So how does this work in a secure environment? The paper doesn't mention any mean for the server to communicate with the network which port its listening on.
My guess is as good as anyone else's, but I surmise it does a bit of packet trickery. Once device A (behind firewall) is connected to device B (may/may not be behind firewall, but at least one port is open, 22 by default in this case), device A can create an SSH tunnel...they really are rather neat and VERY useful as a means of security. For example, I have webmin running on a server, but its port (10 000) is blocked by the firewall. Once I connect to SSH I can redirect packets to a certain IP:Port comb
Re: (Score:2)
Does not make sense tho.
They use UDP to bypass the buffering delays of TCP
If you tunnel UDP in TCP, well.. while you get local echo and state saving.. you might as well type ssh blah.com screen -rd. autossh also auto reconnect 'n stuff. kitty.exe on windows.
Re: (Score:2)
So how does this work in a secure environment?
I would say for the most part it work just like every other protocol that requires inspection by the gateway/firewall device. It will look inside the data stream and fish out the port / address numbers, then store them for later use; it might even change them suit its needs going out. "It can't do that if its encrypted!" you say.
Get with the times if your gateway device does not intercept and MTIM tls/ssl/ssh traffic that you otherwise allow out you are not in a "secure environment".
In this case
Re: (Score:2)
> Since the port number is communicated on an encrypted session, it doesn't have access to that information. So how does this work in a secure environment? The paper doesn't mention any mean for the server to communicate with the network which port its listening on.
I assume that mosh relies on stateful firewalls allowing outbound UDP packets. So, given that the ssh channel allows handshaking, here's what I guess happens:
- Client C connects to Server S through ssh.
- Server S picks a port P, and sends a du
Re: (Score:2)
Port Forwarding? (Score:2)
Does this do things like Port Forwarding? or is this not a replacement for SSH, but almost an extension of it?
I use SSH port forwarding (both directions) compression, and stuff all the time.
Object synchronization is not new... (Score:2)
Heck, people have done that with Objective-C remote proxies have basically been doing that as a form of RPC since NeXT days. Not to mention any other usages of it.
Smooth scrolling terminal (Score:2)
Can we not better (Score:2)
Leave the roaming bit to the layer below it (TCP), or even better - below that (IP) ? It seems more appropriate to not just be able to roam ssh. Not everything is http, you know.
Re:UDP for a connection which has to -reliably- se (Score:5, Insightful)
If they implement their own TCP-like layer over UDP, there's no reason it can't be just as reliable.
It's kind of hard to do things like roaming using TCP because endpoint IPs can change.
Re: (Score:2)
> It's kind of hard to do things like roaming using TCP because endpoint IPs can change.
Bullshit. With UDP you have to abstract the connection so that the source IP can change. With TCP you can do the exact same fucking thing. Close the old socket when you get a connection attempt from a new client with the right handshake.
Re: (Score:3)
Bullshit. With UDP you have to abstract the connection so that the source IP can change. With TCP you can do the exact same fucking thing. Close the old socket when you get a connection attempt from a new client with the right handshake.
I'm a little out of my depth here, but I'd imagine it'd be much easier with UDP because UDP is connectionless. With this sort of roaming, the server isn't expected to change addresses, but the client is. So, have the client sign everything with a negotiated public key, and the server doesn't even have to care where each packet is coming from, or even open any new connections when the client moves across IPs.
Since this is an SSH replacement, I'd expect the key signing to be done already, so once you build an
Re: (Score:3)
In the context of persistent logical connections, you have to consider that the TCP connection will
Re:Why would I want this compatibility break? (Score:5, Insightful)
You, now:
so I can ssh into every server, but only mosh into a few.
You, 1995:
so I can telnet into every server, but only ssh into a few.
Re: (Score:2)
Except the fact that this only solves a problem that exists today (bad 4G coverage, for example), instead of a permanent one (insecure).
Re: (Score:2)
Oh, wait. Flash doesn't play well with mobile browsers. Just like ssh, really, since everytime you switch from one wireless cell to another you may get a new IP address, which would kick you out of your ssh session with no indication that it happened. Which is exact
Re: (Score:3)
Let's see...
I get reconnectability (which I already have, either by using a VPN or by using screen on the server), but now it's built-in.
But now it's automatic.
I get local echo so I have no clue whether my connection has been dropped -- but OTOH, this is great if you have the brain of a goldfish and so can't remember what you just typed for a couple seconds till it gets echoed back. I presume this is optional, so non-goldfish-brains can tell it to 'degrade' to be as useful as ssh.
It also is automatic and shows what hasn't been echoed. Further, typing while lagging by a character or two is incredibly frustrating to almost all brains in existence. It's like listening to headphones which have a half second delay in what you said. Your brain simply freezes.
I get better unicode support -- well, that one's cool, anyway.
And it needs ssh for login, but also needs a mosh server -- so I can ssh into every server, but only mosh into a few.
Am I missing some really great thing about it? It seems like a major hassle for a minor improvement.
What a pessimist.
Re: (Score:2)
Re: (Score:2)
Unicode will be handy for newer systems that may have a more human language interface to it.
Re: (Score:2)
I'm sorry, but that is simply not true. At least not outside the English only speaking world.
ls -l may still be ls -l, but its man page, and the filenames it spits out on stdout are localized, with non US-ASCII characters. The files we view with cat and less are filled with non US-ASCII characters.
Re: (Score:2)
Re: (Score:3)
Once something becomes widely used and stable, making drastic changes becomes next to impossible.
That's why we went CVS -> SVN -> git. Too many people were using CVS to make the changes made in SVN. Too many people are using SVN now to fix the (very old and oft complained about) problems with SVN.
See also NFS. There are issues with NFS that people have complained about for years.. and they will never be fixed for the same reason.
Re: (Score:2)
SVN isn't as fossilized as CVS, but it's still a server-centric architecture, not a distributed version control system. Which has its benefits and d
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Because writing a new RFC for the SSH protocol and then improving the current ubiquitous OpenSSH is an unheard of undertaking.
Re: (Score:2)
As with TLS, I'd like to see any future revisions of these secure protocols trim more fat.
Dude, SSH is half a meg. Calm down.
Re: (Score:2)
As with TLS, I'd like to see any future revisions of these secure protocols trim more fat.
Dude, SSH is half a meg. Calm down.
The problem with "Arcane ciphers, modes, etc" is not executable size at all, but security.
For example, MD2 finally go the axe from openssl back in '09, not because md2 took up too much executable space, but because it was obsolete small / psuedo-broken. I call it psuedo-broken because they crypto guys would call it broken, cracked wide open, but its not totally broken like DRM or copy-protection schemes. Its still has got about 50 bits or so of security, and for many apps that's more than enough, as long
Re: (Score:2)
Re: (Score:2)
> psuedo
Us nuerotic cleuless ueropeans prefer to type "pseudo" in liue of "psuedo". I believe the game "Cleudo" is at blame for your mistake.
Re: (Score:2)
As with TLS, I'd like to see any future revisions of these secure protocols trim more fat.
Dude, SSH is half a meg. Calm down.
I think buddy's point is that SSH should deprecate support for old crypto libs because no one uses them anymore, and they are sort of an Achilles Heal...look at how easily GSM can be subverted because it supports old cypher protocols (and even one that is "No Encryption" encryption!)...anyway, point is: get rid of the stuff no one uses anymore, use only strong crypto with no option for in-the-clear, to reduce the potential for security issues. Our good friend AC just isn't so verbose about his idea...
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
because you trust something that you shouldn't.
Then don't trust it. I don't know why you're having trouble with this.
Re: (Score:3)
When you're operating on a slow wireless connection with an already high amount of traffic on it, every bit counts.
Um, then don't download SSH over a slow wireless connection? Download over a high-speed wired connection and side-load it onto your device.
Re: (Score:2)
When you're operating on a slow wireless connection with an already high amount of traffic on it, every bit counts.
Aw man! Nerdiest double-entendre ever! I'm jealous.
Re: (Score:2)
Is there a mosh iOS app?
They're promising a droid app soon, for the Daft Punk fans...
Re: (Score:2)
No, because mosh is GPLed, and you can't have GPL stuff in the iphone store.
(This doesn't stop someone from reading the protocol spec and writing their own from scratch, of course)
Re:Missed from summary (Score:4, Interesting)
i can't see any idle traffic ... being specified
I looked into MOSH in detail a little while ago and the keepalive packet is every 3 seconds or 3 packets per second can't remember which.
It was often enough to make me pause... that's a lot of traffic if you're metered and paying by the K and/or powered by battery...
Re: (Score:2)
note that ssh does that too and you can configure the amount of time, and/or turn it off entirely (which has its advantages, if connection breaks and comes back you don't lose the session at all. if you change ip, it takes however forever to figure that out)
Re: (Score:2)
Because the sequence number is part of the encrypted payload, and already-seen sequences do not update the state.