avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Custenborder <jcustenbor...@gmail.com>
Subject A couple questions on the RPC spec.
Date Mon, 07 Jun 2010 21:25:13 GMT
This will be my last question for at least the next day or two. :) I just
want to double check my interpretation of the message framing. Assuming that
the client and server have already gone through their handshake. Does this
sound right for a request/response on the wire?

Request:

4 byte length

map of bytes - request metadata

4 byte length

string - message name

for each parameter {

4 byte length

parameter bytes

}

null-terminate

Response:

4 byte length

map of bytes - request metadata

1 byte - 0 or 1 for success

if(false){

4 byte length

bytes containing response

}

else

{

4 byte length

bytes containing error
}


SocketTransceiver seems to support this but it also has this comment stating
it's not standard.

/** A socket-based {@link Transceiver} implementation.  This uses a simple,
 * non-standard wire protocol and is not intended for production services.
*/



A *call* consists of a request message paired with its resulting response or
error message. Requests and responses contain extensible metadata, and both
kinds of messages are framed as described above.

The format of a call request is:

   - *request metadata*, a map with values of type bytes
   - the *message name*, an Avro string, followed by
   - the message *parameters*. Parameters are serialized according to the
   message's request declaration.

The format of a call response is:

   - *response metadata*, a map with values of type bytes
   - a one-byte *error flag* boolean, followed by either:
      - if the error flag is false, the message *response*, serialized per
      the message's response schema.
      - if the error flag is true, the *error*, serialized per the message's
      error union schema.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message