avro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shaun Williams <shaun_willi...@apple.com>
Subject Re: Writing Unsolicited Messages to a Connected Netty Client
Date Fri, 20 Jan 2012 21:21:01 GMT
What about making this explicit in the protocol specification by adding a generic "callback"
request parameter type?

e.g.  void someRequest(callback<ResponseType> cb)

BTW: The NettyTranceiver already prepends a call id to each request and stores the corresponding
callbacks in a  table, so it can easily support out-of-order responses by simply processing
requests in a separate thread.  I proposed a patch this morning to accomplish this:  AVRO-1001.


On Jan 20, 2012, at 1:04 PM, Doug Cutting wrote:

> On 01/20/2012 11:59 AM, Scott Carey wrote:
>> For certain kinds of data it would be useful to continuously stream data
>> from server to client (or vice-versa).
> From client to server this is supported today by using one-way messages
> over a "stateful" transport, like SaslSocket or Netty.
> From server to client this is not currently implemented, but it should
> be possible to extend the wire format to support this, similar to my
> proposal in AVRO-625 (http://s.apache.org/1M5) to add call ids in
> support of out-of-order responses.
> To support server-to-client messages one might add to the metadata of
> each request isRequest=true and for responses add isResponse=true.  Then
> both client and server could examine each framed message that arrives
> and determine its intent.  If a client reads a request then it parses it
> as such and writes a response (unless the request is one way).
> The initial request sent to a client should be prefixed by a
> HandshakeRequest, itself preceded by a metadata list containing just
> isHandshakeRequest=true.  Thus server-to-client messages could use a
> different protocol than client-to-server messages.
> To make this compatible we would add to the client's HandshakeRequest
> metadata supportsCallbacks=true.  A server would only attempt callbacks
> with clients that declared this when they connect.  Similarly, if the
> server's HandshakeResponse does not include supportsCallbacks=true then
> the client should not expect to receive any callbacks.
> Doug

View raw message