Doug, There are a few reasons why I am interested in the netty server:
1) I hope to use avro only for communication on an internal network, so I don't care so much about encryption and authorization and prefer not to have the extra overhead. 2) In the absence of AVRO-625 being implemented, the netty server can most easily be extended to allow out-of-order responses. One of my components is c++, so I need a c++ RPC implementation. At this point, though, if I were to build one, It's not clear to me which wire format to implement. The netty server format is the simplest, yet I'm worried that it might be deprecated. Thanks for you help! -Shaun On Jan 20, 2012, at 4:41 PM, Doug Cutting wrote: > On 01/20/2012 04:16 PM, Shaun Williams wrote: >> 1) It prepends an 8 byte header to each request/response which >> encodes a call id and the number of frames to follow. 2) It uses the >> number of frames value above to decide when to stop reading as >> opposed to writing a zero length frame. > > The rationale for null-termination is to permit streaming of data that's > larger than can easily be buffered, i.e., so you can send requests or > responses whose full length is unknown when you start to encode them. > >> From what I can tell that protocol is unique, e.g. a Netty client can >> only talk to Netty server (java to java). >> >> I'm wondering what is the plan for supporting this? Will plain >> socket implementations on other platforms implement this or something >> else? > > Encryption and authorization are supported by the SaslSocket > implementation. The SASL profile is defined at: > > http://avro.apache.org/docs/current/sasl.html > > To maximize interoperability, we should try to settle on a single > socket-based wire format that permits both good performance as well as > secure implementations. My hope is that SaslSocket plus call IDs would > form that. My proposal to add call ids is in AVRO-625 > (http://s.apache.org/1M5). > > We could add call IDs at the framing layer as the Netty implementation > has done, but it is more compatible to take advantage of the extensible > metadata that already accompanies each message on the wire. > > Doug
