On 10/04/2011 02:49 PM, Wade Chandler wrote:
> I'm very interested in multiple protocol support if there is any
> chance such support being added would be accepted unless it is
> already on the list of things to do; in that case I would gladly help
> out if I can.
I don't know of anyone currently working on this. A good implementation
would be welcome.
> Seems in this situation I would have to have specific client
> connections versus all messages traveling over a single connection
> with merged protocols. i.e. Each individual client connection
> performs its own hand shake and thus each one is using a specific
> protocol on the connection. Is that correct?
If you use HTTP then each protocol can be at a different URL. HTTP
clients pool connections to a given server, so that different protocols
can share a single connection. If HTTP is suitable for your RPC needs
then you might not need to implement anything new. Other transceiver
implementations do not currently pool connections but represent a
dedicated connection ("stateful" in the terminology of Avro's
specification.)
> This too makes me feel like a better solution would be to allow
> multiple protocols to be used for RPC.
A simple way to implement this might be to make other Transceivers be
"stateless" like HttpTransceiver. (This is easy to implement: just
override isConnected to always return false.) Then every client request
will be prefixed by the protocol handshake, uniquely identifying the
protocol. (The handshake is only a pair of 16-byte MD5 hash codes, so
only adds ~32 bytes to each request.) Existing client code should not
otherwise need to be changed. Stateless Transceivers should already be
able to be used by multiple Requestors.
The primary change would be on the server side. Responder's constructor
would need to accept a list of multiple protocols. Responder#respond()
could be passed the remote protocol. SpecificResponder would accept a
list of implementations and dispatch based on the handshake.
Doug
