Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Avro >> mail # dev >> RPC multiplexing


Copy link to this message
-
RE: RPC multiplexing
Doug Cutting wrote:

> Requiring servers to copy the call-id to responses
> is an incompatible change.  So is adding a magic number.

Do we want to introduce these incompatible changes in 1.3? If yes, I can
file a JIRA and work on it. In 1.3 we can just introduce the simple
(synchronous) client and server.

Since the servers should anyway respect call-id, shall we also say that
every request should have a call-id. The simple (synchronous) client may
send the same id for every request. Since, with a synchronous client, there
won't be more than one request outstanding at any given point in time,
sending the same call-id is fine. This simplifies the protocol as there are
no conditional elements in the request. This proposal makes the current
client and server incompatible. Doug's original proposal makes only the
server incompatible.

What do you think?

Thiru

-----Original Message-----
From: Doug Cutting [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 06, 2010 1:26 AM
To: [EMAIL PROTECTED]
Subject: Re: RPC multiplexing

Philip Zeyliger wrote:
> Thinking out loud, the handshake could negotiate not just the schema for
the
> protocol, but also the schema for the RPC metadata.

So we'd send a hash of the handshake's schema too?  I think sending a
magic number is equivalent and simpler.

> Is the call-id value arbitrary bytes?  We wouldn't break compatibility
with
> what's currently published if the server was allowed to not set call-id if
> it was responding to things in order.

Yes, you're right.  Requiring servers to copy the call-id to responses
is an incompatible change.  So is adding a magic number.  But the spec
currently does not yet define any transports, only request and response
messages, which do not change.  So we can consider this requirement and
the addition of a magic number as a part of the specification of a
TCP-based transport and label the existing implementation non-conforming.

Doug