Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Avro >> mail # user >> Parsing canonical form of protocol definitions


Copy link to this message
-
Re: Parsing canonical form of protocol definitions
The RPC handshake was designed to be tolerant of differences in the
protocol hashing method.  The java implementation uses MD5 of the
protocol's un-normalized text.  This could result in the needless
transmission over the wire of protocols that only differ in trivial
ways, but since clients and servers cache these, they should't be
transmitted often.

A server should cache a client's protocol using the client-computed
hash as key.  So if two clients hash schemas differently then the
server will end up with two entries in its cache.  This permits
variation in implementation (intentional or not).

Does that help?

Doug

On Sun, Mar 17, 2013 at 9:16 PM, Connor Doyle <[EMAIL PROTECTED]> wrote:
> I've started working on a reflective Avro library for the Scala programming
> language.
>
> The description of Parsing Canonical Form is clear enough for schemas, but I
> can't seem to find any mention of prescribed ordering of the "types" field
> for protocol definitions in the current specification.  I've based my first
> pass on forward declarations elimination, but this gives only a partial
> order.
>
> In the absence of spec I can base behavior on the reference (Java)
> implementation, but am curious about this aspect of the handshake.
> --
> Connor
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB