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