{"action":"created","issue":{"url":"https://api.github.com/repos/uProxy/uproxy-networking/issues/203","labels_url":"https://api.github.com/repos/uProxy/uproxy-networking/issues/203/labels{/name}","comments_url":"https://api.github.com/repos/uProxy/uproxy-networking/issues/203/comments","events_url":"https://api.github.com/repos/uProxy/uproxy-networking/issues/203/events","html_url":"https://github.com/uProxy/uproxy-networking/pull/203","id":58651525,"number":203,"title":"improve responsiveness of SocksToRtc and RtcToNet queue processing","user":{"login":"trevj","id":5142116,"avatar_url":"https://avatars.githubusercontent.com/u/5142116?v=3","gravatar_id":"","url":"https://api.github.com/users/trevj","html_url":"https://github.com/trevj","followers_url":"https://api.github.com/users/trevj/followers","following_url":"https://api.github.com/users/trevj/following{/other_user}","gists_url":"https://api.github.com/users/trevj/gists{/gist_id}","starred_url":"https://api.github.com/users/trevj/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/trevj/subscriptions","organizations_url":"https://api.github.com/users/trevj/orgs","repos_url":"https://api.github.com/users/trevj/repos","events_url":"https://api.github.com/users/trevj/events{/privacy}","received_events_url":"https://api.github.com/users/trevj/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":{"login":"bemasc","id":191945,"avatar_url":"https://avatars.githubusercontent.com/u/191945?v=3","gravatar_id":"","url":"https://api.github.com/users/bemasc","html_url":"https://github.com/bemasc","followers_url":"https://api.github.com/users/bemasc/followers","following_url":"https://api.github.com/users/bemasc/following{/other_user}","gists_url":"https://api.github.com/users/bemasc/gists{/gist_id}","starred_url":"https://api.github.com/users/bemasc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bemasc/subscriptions","organizations_url":"https://api.github.com/users/bemasc/orgs","repos_url":"https://api.github.com/users/bemasc/repos","events_url":"https://api.github.com/users/bemasc/events{/privacy}","received_events_url":"https://api.github.com/users/bemasc/received_events","type":"User","site_admin":false},"milestone":null,"comments":5,"created_at":"2015-02-23T21:29:34Z","updated_at":"2015-02-23T23:12:07Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/uProxy/uproxy-networking/pulls/203","html_url":"https://github.com/uProxy/uproxy-networking/pull/203","diff_url":"https://github.com/uProxy/uproxy-networking/pull/203.diff","patch_url":"https://github.com/uProxy/uproxy-networking/pull/203.patch"},"body":"So, inspired by this pull request:\r\nhttps://github.com/uProxy/uproxy-lib/pull/126/files\r\n\r\nThis greatly improves the responsiveness of the proxy under high load. Specifically, with this change the proxy is sitll responsive while there is a fast download taking place, e.g.:\r\n 1. start curl-ing a large file\r\n 1. try to browse \"normal\" web pages with a browser\r\n\r\nThis does not currently work. General idea is to yield after each fetch from the socket and data channel's queue. More info here:\r\nhttps://github.com/uProxy/uproxy/issues/967\n\n<!-- Reviewable:start -->\n[<img src=\"https://reviewable.io/review_button.png\" height=40 alt=\"Review on Reviewable\"/>](https://reviewable.io/reviews/uproxy/uproxy-networking/203)\n<!-- Reviewable:end -->\n"},"comment":{"url":"https://api.github.com/repos/uProxy/uproxy-networking/issues/comments/75658663","html_url":"https://github.com/uProxy/uproxy-networking/pull/203#issuecomment-75658663","issue_url":"https://api.github.com/repos/uProxy/uproxy-networking/issues/203","id":75658663,"user":{"login":"bemasc","id":191945,"avatar_url":"https://avatars.githubusercontent.com/u/191945?v=3","gravatar_id":"","url":"https://api.github.com/users/bemasc","html_url":"https://github.com/bemasc","followers_url":"https://api.github.com/users/bemasc/followers","following_url":"https://api.github.com/users/bemasc/following{/other_user}","gists_url":"https://api.github.com/users/bemasc/gists{/gist_id}","starred_url":"https://api.github.com/users/bemasc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bemasc/subscriptions","organizations_url":"https://api.github.com/users/bemasc/orgs","repos_url":"https://api.github.com/users/bemasc/repos","events_url":"https://api.github.com/users/bemasc/events{/privacy}","received_events_url":"https://api.github.com/users/bemasc/received_events","type":"User","site_admin":false},"created_at":"2015-02-23T23:12:07Z","updated_at":"2015-02-23T23:12:07Z","body":"@trevj and I spent a while discussing this and we have a tentative understanding.  Essentially, the pull request to make datachannel.ts slow down at the buffer limit did not actually work.  If it had worked, this would not be necessary: RtcToNet would pile all incoming data directly into the DataChannel queue, which would only pull it out one message at a time while checking getBufferedAmount, which should effectively give priority to the connections that send the least data.  Instead, we see the opposite behavior.\r\n\r\nWe don't know why this didn't work, but in the interest of unblocking closed beta, we can land this patch, and I will try to investigate why that code doesn't behave as expected.\r\n\r\nThis patch introduces a sort of bucket brigade, with two successive points (in one thread) where one queue is drained into another, one message at a time, asynchronously (using setTimeout).  This should not be necessary, and perhaps it can be simplified (e.g. https://github.com/uProxy/uproxy/issues/979) once we understand why datachannel.ts is not behaving as expected.\r\n\r\n:+1:"}}