{"action":"created","issue":{"url":"https://api.github.com/repos/tokio-rs/tokio-proto/issues/170","repository_url":"https://api.github.com/repos/tokio-rs/tokio-proto","labels_url":"https://api.github.com/repos/tokio-rs/tokio-proto/issues/170/labels{/name}","comments_url":"https://api.github.com/repos/tokio-rs/tokio-proto/issues/170/comments","events_url":"https://api.github.com/repos/tokio-rs/tokio-proto/issues/170/events","html_url":"https://github.com/tokio-rs/tokio-proto/issues/170","id":233405474,"number":170,"title":"How to handle protocols that are not entirely multiplexed?","user":{"login":"little-dude","id":6646324,"avatar_url":"https://avatars1.githubusercontent.com/u/6646324?v=3","gravatar_id":"","url":"https://api.github.com/users/little-dude","html_url":"https://github.com/little-dude","followers_url":"https://api.github.com/users/little-dude/followers","following_url":"https://api.github.com/users/little-dude/following{/other_user}","gists_url":"https://api.github.com/users/little-dude/gists{/gist_id}","starred_url":"https://api.github.com/users/little-dude/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/little-dude/subscriptions","organizations_url":"https://api.github.com/users/little-dude/orgs","repos_url":"https://api.github.com/users/little-dude/repos","events_url":"https://api.github.com/users/little-dude/events{/privacy}","received_events_url":"https://api.github.com/users/little-dude/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2017-06-04T01:29:33Z","updated_at":"2017-06-22T19:29:05Z","closed_at":null,"body":"For some protocols like msgpack-rpc or json-rpc, some requests have IDs and expect a responses with the same IDs, but they also have notifications, which don't have IDs and don't expect a response. I'm not sure how to handle this.\r\n\r\nWhen decoding messages without an ID, I can just create a fake one (`u64::max_value()` for example). The real problem is when implementing the service. For a client it will look like this:\r\n\r\n```rust\r\nimpl Service for Client {\r\n    type Request = Message;\r\n    type Response = Message;\r\n    type Error = io::Error;\r\n    type Future = Box<Future<Item = Message, Error = io::Error>>;\r\n\r\n    fn call(&self, req: Self::Request) -> Self::Future {\r\n        // my future will never return for messages that don't expect a response\r\n    }\r\n}\r\n```\r\n\r\nSo is tokio-proto what I really need for such protocols? If not, what should I look at implementing?"},"comment":{"url":"https://api.github.com/repos/tokio-rs/tokio-proto/issues/comments/310478972","html_url":"https://github.com/tokio-rs/tokio-proto/issues/170#issuecomment-310478972","issue_url":"https://api.github.com/repos/tokio-rs/tokio-proto/issues/170","id":310478972,"user":{"login":"carllerche","id":6180,"avatar_url":"https://avatars0.githubusercontent.com/u/6180?v=3","gravatar_id":"","url":"https://api.github.com/users/carllerche","html_url":"https://github.com/carllerche","followers_url":"https://api.github.com/users/carllerche/followers","following_url":"https://api.github.com/users/carllerche/following{/other_user}","gists_url":"https://api.github.com/users/carllerche/gists{/gist_id}","starred_url":"https://api.github.com/users/carllerche/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/carllerche/subscriptions","organizations_url":"https://api.github.com/users/carllerche/orgs","repos_url":"https://api.github.com/users/carllerche/repos","events_url":"https://api.github.com/users/carllerche/events{/privacy}","received_events_url":"https://api.github.com/users/carllerche/received_events","type":"User","site_admin":false},"created_at":"2017-06-22T19:29:05Z","updated_at":"2017-06-22T19:29:05Z","body":"TcpServer might be able to be broken out into a separate lib..."}}
{"actor":{"display_login":"carllerche"}}