{"action":"created","issue":{"url":"https://api.github.com/repos/mobile-shell/mosh/issues/832","repository_url":"https://api.github.com/repos/mobile-shell/mosh","labels_url":"https://api.github.com/repos/mobile-shell/mosh/issues/832/labels{/name}","comments_url":"https://api.github.com/repos/mobile-shell/mosh/issues/832/comments","events_url":"https://api.github.com/repos/mobile-shell/mosh/issues/832/events","html_url":"https://github.com/mobile-shell/mosh/issues/832","id":192446938,"number":832,"title":"Long delays or stalls when refreshing terminals with lots of static text over a slow link","user":{"login":"karlkec","id":982120,"avatar_url":"https://avatars.githubusercontent.com/u/982120?v=3","gravatar_id":"","url":"https://api.github.com/users/karlkec","html_url":"https://github.com/karlkec","followers_url":"https://api.github.com/users/karlkec/followers","following_url":"https://api.github.com/users/karlkec/following{/other_user}","gists_url":"https://api.github.com/users/karlkec/gists{/gist_id}","starred_url":"https://api.github.com/users/karlkec/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/karlkec/subscriptions","organizations_url":"https://api.github.com/users/karlkec/orgs","repos_url":"https://api.github.com/users/karlkec/repos","events_url":"https://api.github.com/users/karlkec/events{/privacy}","received_events_url":"https://api.github.com/users/karlkec/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2016-11-30T01:01:56Z","updated_at":"2016-11-30T02:06:32Z","closed_at":null,"body":"There are sometimes excessively long refresh delays with a slow link and a terminal with lots of unchanging text.  When switching between tmux windows with lots of static text on a 475x125 character console, it can take many seconds to hours to refresh the terminal. Sometimes it completely stalls with the terminal partially refreshed, and while refreshing it saturates the server-to-client connection. Neither the client nor server are taking excessive CPU. The client indicates a lost connection, but if I type a hot key on the client to switch tmux at the far end to a sparsely populated window, the whole thing recovers. It fails again as soon as tmux is switched to a window with lots of text.\r\nAn ssh connection at the same time to the same tmux window refreshes in a couple of seconds."},"comment":{"url":"https://api.github.com/repos/mobile-shell/mosh/issues/comments/263761354","html_url":"https://github.com/mobile-shell/mosh/issues/832#issuecomment-263761354","issue_url":"https://api.github.com/repos/mobile-shell/mosh/issues/832","id":263761354,"user":{"login":"cgull","id":1934797,"avatar_url":"https://avatars.githubusercontent.com/u/1934797?v=3","gravatar_id":"","url":"https://api.github.com/users/cgull","html_url":"https://github.com/cgull","followers_url":"https://api.github.com/users/cgull/followers","following_url":"https://api.github.com/users/cgull/following{/other_user}","gists_url":"https://api.github.com/users/cgull/gists{/gist_id}","starred_url":"https://api.github.com/users/cgull/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cgull/subscriptions","organizations_url":"https://api.github.com/users/cgull/orgs","repos_url":"https://api.github.com/users/cgull/repos","events_url":"https://api.github.com/users/cgull/events{/privacy}","received_events_url":"https://api.github.com/users/cgull/received_events","type":"User","site_admin":false},"created_at":"2016-11-30T02:06:32Z","updated_at":"2016-11-30T02:06:32Z","body":"Anders is correct in suggesting that this is probably an MTU problem, but there is one other possibility worth mentioning:  Mosh communicates via application datagrams that can theoretically reach 50MB in size.  These are fragmented into separate UDP datagrams by the sender and reassembled by the receiver.  If any single fragment goes missing then the entire message is lost.  (UDP fragmentation may also happen underneath this layer as well.)  Also, the fragment reassembly is quite simple-minded, and if fragments for two separate messages are interleaved, one of the messages will be lost.\r\n\r\nI've not actually seen this problem, but your console windows are pretty big (larger than anything I regularly use), and I think messages for windows this big might be at some risk of never being successfully delivered on networks with high loss, or with queues too short to handle all the packets in a message.  Can you characterize your network link's performance at all?\r\n"}}
{"actor":{"display_login":"cgull"}}