{"action":"created","issue":{"url":"https://api.github.com/repos/reactive-ipc/reactive-ipc-jvm/issues/21","labels_url":"https://api.github.com/repos/reactive-ipc/reactive-ipc-jvm/issues/21/labels{/name}","comments_url":"https://api.github.com/repos/reactive-ipc/reactive-ipc-jvm/issues/21/comments","events_url":"https://api.github.com/repos/reactive-ipc/reactive-ipc-jvm/issues/21/events","html_url":"https://github.com/reactive-ipc/reactive-ipc-jvm/issues/21","id":65327387,"number":21,"title":"Multiplexing TCP Writes","user":{"login":"benjchristensen","id":813492,"avatar_url":"https://avatars.githubusercontent.com/u/813492?v=3","gravatar_id":"","url":"https://api.github.com/users/benjchristensen","html_url":"https://github.com/benjchristensen","followers_url":"https://api.github.com/users/benjchristensen/followers","following_url":"https://api.github.com/users/benjchristensen/following{/other_user}","gists_url":"https://api.github.com/users/benjchristensen/gists{/gist_id}","starred_url":"https://api.github.com/users/benjchristensen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/benjchristensen/subscriptions","organizations_url":"https://api.github.com/users/benjchristensen/orgs","repos_url":"https://api.github.com/users/benjchristensen/repos","events_url":"https://api.github.com/users/benjchristensen/events{/privacy}","received_events_url":"https://api.github.com/users/benjchristensen/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":15,"created_at":"2015-03-30T23:30:20Z","updated_at":"2015-04-02T20:00:03Z","closed_at":null,"body":"A `TcpConnection` should support multiple writes to allow multiplexing. I suggest also that flush semantics need to be supported per writer. \r\n\r\nFor example:\r\n\r\n```java\r\nwrite(publisherA);\r\nwrite(publisherB);\r\n```\r\n\r\nBoth A and B can `onNext` on the same TCP connection and then it depends on the protocol to order the messages if required. e.g.: When implementing an HTTP/2 kind of protocol, when there can be multiple streams on the same connection, and every stream frame is independent, one can write the items without the need of ordering across streams. \r\n\r\nThis could instead be done by forcing our APIs to only allow a single `Publisher` to be given to a connection, but then we should not have a `write` method that can be called more than once. \r\n\r\nI suggest that `write(Publisher<T> p)` (or something matching this signature) exist and that it must support multiple concurrent writers/publishers so that multiplexing is embraced.\r\n\r\nI also suggest that each writer needs to be able to control flush semantics independently of other writers. \r\n\r\nContinuing the example above, if \"A\" and \"B\" are both writing, but \"A\" doesn't care when it flushes but \"B\" does, \"B\" should be able to trigger a flush which will of course flush messages from both \"A\" and \"B\", but is only triggered by \"B\". \r\n\r\nOr \"A\" and \"B\" could have different logic as to when they need to flush and are both permitted independently to trigger flush semantics. \r\n\r\nOne approach to this is overloading the write method to support each writer providing it's own control for flushing so if \"A\" does not care but \"B\" does it could be like this:\r\n\r\n```java\r\nwrite(publisherA);\r\nwrite(publisherB, flushSelector);\r\n```"},"comment":{"url":"https://api.github.com/repos/reactive-ipc/reactive-ipc-jvm/issues/comments/89026106","html_url":"https://github.com/reactive-ipc/reactive-ipc-jvm/issues/21#issuecomment-89026106","issue_url":"https://api.github.com/repos/reactive-ipc/reactive-ipc-jvm/issues/21","id":89026106,"user":{"login":"jbrisbin","id":55797,"avatar_url":"https://avatars.githubusercontent.com/u/55797?v=3","gravatar_id":"","url":"https://api.github.com/users/jbrisbin","html_url":"https://github.com/jbrisbin","followers_url":"https://api.github.com/users/jbrisbin/followers","following_url":"https://api.github.com/users/jbrisbin/following{/other_user}","gists_url":"https://api.github.com/users/jbrisbin/gists{/gist_id}","starred_url":"https://api.github.com/users/jbrisbin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jbrisbin/subscriptions","organizations_url":"https://api.github.com/users/jbrisbin/orgs","repos_url":"https://api.github.com/users/jbrisbin/repos","events_url":"https://api.github.com/users/jbrisbin/events{/privacy}","received_events_url":"https://api.github.com/users/jbrisbin/received_events","type":"User","site_admin":false},"created_at":"2015-04-02T20:00:03Z","updated_at":"2015-04-02T20:00:03Z","body":"The idea behind `DemandCalculator` is to provide a `Subscriber` with additional information about what possible values it can use in the next `Subscription.request()` call. It doesn't have to take that information into account. But it's a way to make the request size flexible and configurable and informed by information other than what the `Subscriber` has access to (which isn't much)."}}