Bruce, Overall this looks like a good approach to me.
How do you anticipate allocating channels? I'm guessing this would be one per client object, that a pool of open connections to servers would be maintained, and creating a new client object would allocate a new channel.
Currently we perform a handshake per request. This is fairly cheap and permits things like routing through proxy servers. Different requests over the same connection can talk to different backend servers running different versions of the protocol. Also consider the case where, between calls on an object, the connection times out, and a new session is established and a new handshake must take place.
That said, having a session where the handshake can be assumed vastly simplifies one-way messages. Without a response or error on which to prefix a handshake response, a one-way client has no means to know that the server was able to even parse its request. Yet we'd still like a handshake for one-way messages, so that clients and servers need not be versioned in lockstep. So the handshake-per-request model doesn't serve one-way messages well.
How can we address both of these needs: to permit flexible payload routing and efficient one-way messaging?
Doug Bruce Mitchener wrote:
* Think about adding something for true one-way messages, but an empty reply frame is probably sufficient, since that still allows reporting errors if needed (or desired).
