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
