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
