{"action":"opened","issue":{"url":"https://api.github.com/repos/GGist/redox-rs/issues/11","labels_url":"https://api.github.com/repos/GGist/redox-rs/issues/11/labels{/name}","comments_url":"https://api.github.com/repos/GGist/redox-rs/issues/11/comments","events_url":"https://api.github.com/repos/GGist/redox-rs/issues/11/events","html_url":"https://github.com/GGist/redox-rs/issues/11","id":112220807,"number":11,"title":"[On Hold Until Merge] Investigate scalability of BTHandshaker","user":{"login":"GGist","id":5248583,"avatar_url":"https://avatars.githubusercontent.com/u/5248583?v=3","gravatar_id":"","url":"https://api.github.com/users/GGist","html_url":"https://github.com/GGist","followers_url":"https://api.github.com/users/GGist/followers","following_url":"https://api.github.com/users/GGist/following{/other_user}","gists_url":"https://api.github.com/users/GGist/gists{/gist_id}","starred_url":"https://api.github.com/users/GGist/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GGist/subscriptions","organizations_url":"https://api.github.com/users/GGist/orgs","repos_url":"https://api.github.com/users/GGist/repos","events_url":"https://api.github.com/users/GGist/events{/privacy}","received_events_url":"https://api.github.com/users/GGist/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-10-19T19:58:48Z","updated_at":"2015-10-19T19:58:48Z","closed_at":null,"body":"The ```BTHandshaker``` implementation which is part of the ```dht_support``` branch is structured to provide a common object to perform handshaking with connections from sources such as trackers, dhts, local peer discovery, or other discovery mechanisms.\r\n\r\nAt the moment, some initial benchmarking has been done and under full load the handshaker blows up and causes system instability. Initially it looks like it was creating too many system handles so a ```ThreadPool``` has been used to cap the amount of thread handles generated. This improved the stability greatly but it looks like it is possible to also create too many ```TcpStreams``` on both connection initiation, and completion via ```TcpListener```.\r\n\r\nAt this point, the ```ThreadPool``` should act as a throttle for connection initiation, but the ```TcpListener``` thread may be causing too many ```TcpListener``` handles to be created. We should investigate whether a ```SyncSender``` can solve this and where the sweet spot is in terms of performance for capping the number of completion worker messages."}}