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. Shaun 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
