On Thu, May 4, 2017 at 2:14 PM, Jacob Barrett <jbarr...@pivotal.io> wrote:
> > > One benefit of messageHeader with chunk is that, it gives us ability to > > > write different messages(multiplexing) on same socket. And if thread is > > > ready it can write its message. Though we are not there yet, but that > will > > > require for single socket async architecture. > > > > > > > I wouldn't tackle that at this layer. I would suggest adding a layer > > between the message and TCP that creates channels that are opaque to the > > message layer above. The message layer wouldn't know if it was talking to > > multiple sockets to the client or single socket with multiple channels. > > Though we haven't really discussed it explicitly, the new protocol is > adding the correlationID in the expectation that at some point it will be > possible to execute requests out-of-order. One alternative to correlationID > if we had multiple channels would be to use one channel per message or set > of (ordered) messages. This would be a bit expensive if we used separate > sockets for each, but if we had channels built into the protocol, it would > be fine. The other use of correlationID might be for retries or to check up > on a message after some issue leading to a disconnect. However, we have the > EventID for that. > > As far as I know, we don't have the async, out-of-order functionality yet. > I believe that in the current protocol, messages are ordered and > synchronous -- they only happen in the order they're sent, and each > operation blocks for the previous one to finish (though you could use > multiple connections to get similar functionality). > My discussion here was around the concept of interleaving chunks of individual messages not out of order responses of individual messages. From the end user's perspective though whether we used correlation IDs or ordered request/response over channels is irrelevant. At that level the API should be asynchronous anyway. Underneath we can decide that if a single channel/socket can have out of order messaging (not to be confused with out of order partial message interleaving) or correlation ID. Interleaving meaning [Req1.1][Req2.1][Res2.1][Req1.2][Res1.1][Res2.2][Res1.2] Correlation and part index required Out of order meaning: [Req1][Req2][Res2][Res2] Correlation ID required In order over channel: 1: [Req.1] [Req.2][Res.1] [Res.2] 2: [Req.1][Res.1] [Res.2] No correlation or ID required. Each request pulls a channel from a pool. Naive approach is sockets, advanced is channel sublayer on the stack. I really think In Order Over makes life easier. Maybe a hybrid approach exists with Correlation IDs and Channels but really you can solve the same problem with just channels, just more of them. At a Channel level it would look synchronous request/response. -Jake
