I think bidirectional communications support is an important feature that should be addressed as a standalone Jira.
In regard to Roger’s comment, perhaps 563 could be given a transparent fast mode. Anytime the service string is 4 bytes or less it could be used as an i32 key. Thus if you want fast operations all you need do is keep your service IDs 4 chars or less. When the TMultiplexedProtocol sees a service ID <= 4 chars it uses a message that begins with the separator followed by the 4 byte key and then the normal “name” payload.
The TMultiplexedProcessor in this scenario would check byte 0 for the separator, if found it would take the fast code path, no parsing just extract the key and call through to the correct service. Should be as fast as the byte solution. Longer service names would be processed as they are now. Calls without a separator could invoke a default service. This would give us fast, flexible and backward compatible in one package.However it works, I think a fast key lookup would be nice.
Repurposing one of the Protocol version bytes seems problematic. It entangles the multiplexing concern with the otherwise encapsulated operations of the Protocol. It is really a message routing issue and plugging it into the message name seems pretty logical. Onthe pragmatic side, there may be protocols out there that implement TProtocol but have no spare bytes to use. For example, the JSON Protocol Version is a text based number, could work, but starts getting strange. The compact protocol has a one byte ID and a one byte Version packed with the message type, leaving no obvious way to hook in the channel byte.