I am trying to figure out how a message can be sent through a Netty Server
to a connected client.  I see the channel is stored in a group for each
client that connects to a Netty Server:

public void channelOpen(ChannelHandlerContext ctx, ChannelStateEvent e)
throws Exception
{
     e.getChannel().write(null);
     *allChannels.add(e.getChannel());*
     super.channelOpen(ctx, e);
}

The challenge is how to leverage this channel in order to send an
unsolicited message to the client.  Is there an example that writes to the
channel but not as a response to a message received?

I fully expect to take the existing Netty Server and modify it.  I suspect
the solution lies somewhere in creating a NettyDataPack then writing it to
the channel.  I'm definitely an Avro  greenhorn, so I'm a bit unsure of how
to wrangle my message into a NettyDataPack.

           -Armin

Hi Armin,

Could you explain a little more about what you're trying to do?  It sounds
like you want a protocol in which either client or the server initiates a
remote procedure call.  The easiest way to do this is to have the client
also be a server and the server also be a client.  For example, consider
the following protocols:

protocol WeatherClient {
  double getTemperature(string postalCode);
  void registerForTemperatureUpdates(string postalCode, string clientHost,
int clientPort);
}

protocol WeatherUpdateListener {
  void onTemperatureUpdate(String postalCode, double newTemperature);
}

The client side would use WeatherClient (and
SpecificRequestor/NettyTransceiver) to request the temperature for some
postal code from the server.  The client could also register with the
server for temperature updates by passing the postal code it's interested
in as well as the hostname/IP and port of a netty server running on the
client.  The client would run its own netty server using a
WeatherUpdateListener and SpecificResponder.  When the server has a
temperature update to send back to the client, it would send a message to
the client using the WeatherUpdateListener interface.  Is this close to
what you're looking for?

-James
On Fri, Jan 20, 2012 at 6:34 AM, Armin Garcia <[EMAIL PROTECTED]>wrote:

> I am trying to figure out how a message can be sent through a Netty Server
> to a connected client.  I see the channel is stored in a group for each
> client that connects to a Netty Server:
>
> public void channelOpen(ChannelHandlerContext ctx, ChannelStateEvent e)
> throws Exception
> {
>      e.getChannel().write(null);
>      *allChannels.add(e.getChannel());*
>      super.channelOpen(ctx, e);
> }
>
> The challenge is how to leverage this channel in order to send an
> unsolicited message to the client.  Is there an example that writes to the
> channel but not as a response to a message received?
>
> I fully expect to take the existing Netty Server and modify it.  I suspect
> the solution lies somewhere in creating a NettyDataPack then writing it to
> the channel.  I'm definitely an Avro  greenhorn, so I'm a bit unsure of how
> to wrangle my message into a NettyDataPack.
>
>            -Armin
>
>
>

Hi James,

First, thank you for your response.

Yes, you are right.  I am trying to setup a bi-directional communication
link.  Your suggestion would definitely accomplish this requirement.  I was
hoping the same channel could be reused without having to establish another
uni-directional link.  Netty or rather NIO is inherently bi-directional.  I
am suspecting RPC by definition is only uni-directional or rather a pull
technology?

One of my goals is to support as many different language bindings using
Avro.  PHP is one of those languages.  Unfortunately, the PHP library can
only function as a client.

               -Armin

On Fri, Jan 20, 2012 at 7:47 AM, James Baldassari <[EMAIL PROTECTED]>wrote:

> Hi Armin,
>
> Could you explain a little more about what you're trying to do?  It sounds
> like you want a protocol in which either client or the server initiates a
> remote procedure call.  The easiest way to do this is to have the client
> also be a server and the server also be a client.  For example, consider
> the following protocols:
>
> protocol WeatherClient {
>   double getTemperature(string postalCode);
>   void registerForTemperatureUpdates(string postalCode, string clientHost,
> int clientPort);
> }
>
> protocol WeatherUpdateListener {
>   void onTemperatureUpdate(String postalCode, double newTemperature);
> }
>
> The client side would use WeatherClient (and
> SpecificRequestor/NettyTransceiver) to request the temperature for some
> postal code from the server.  The client could also register with the
> server for temperature updates by passing the postal code it's interested
> in as well as the hostname/IP and port of a netty server running on the
> client.  The client would run its own netty server using a
> WeatherUpdateListener and SpecificResponder.  When the server has a
> temperature update to send back to the client, it would send a message to
> the client using the WeatherUpdateListener interface.  Is this close to
> what you're looking for?
>
> -James
>
>
>
> On Fri, Jan 20, 2012 at 6:34 AM, Armin Garcia <[EMAIL PROTECTED]>wrote:
>
>> I am trying to figure out how a message can be sent through a Netty
>> Server to a connected client.  I see the channel is stored in a group for
>> each client that connects to a Netty Server:
>>
>> public void channelOpen(ChannelHandlerContext ctx, ChannelStateEvent e)
>> throws Exception
>> {
>>      e.getChannel().write(null);
>>      *allChannels.add(e.getChannel());*
>>      super.channelOpen(ctx, e);
>> }
>>
>> The challenge is how to leverage this channel in order to send an
>> unsolicited message to the client.  Is there an example that writes to the
>> channel but not as a response to a message received?
>>
>> I fully expect to take the existing Netty Server and modify it.  I
>> suspect the solution lies somewhere in creating a NettyDataPack then
>> writing it to the channel.  I'm definitely an Avro  greenhorn, so I'm a bit
>> unsure of how to wrangle my message into a NettyDataPack.
>>
>>            -Armin
>>
>>
>>
>

Another solution is to use the response leg of a transaction to push messages to the client, e.g. provide a server protocol like this:

WeatherUpdate listenForUpdate();

This would essentially block until an update is available.  The only problem is that if the client is expecting a series of updates, it would need to call this method again after receiving each update.

This is not an ideal solution, but it might solve your problem.

-Shaun
On Jan 20, 2012, at 8:24 AM, Armin Garcia wrote:

> Hi James,
>  
> First, thank you for your response.
>  
> Yes, you are right.  I am trying to setup a bi-directional communication link.  Your suggestion would definitely accomplish this requirement.  I was hoping the same channel could be reused without having to establish another uni-directional link.  Netty or rather NIO is inherently bi-directional.  I am suspecting RPC by definition is only uni-directional or rather a pull technology?
>  
> One of my goals is to support as many different language bindings using Avro.  PHP is one of those languages.  Unfortunately, the PHP library can only function as a client.
>  
>                -Armin
>
> On Fri, Jan 20, 2012 at 7:47 AM, James Baldassari <[EMAIL PROTECTED]> wrote:
> Hi Armin,
>
> Could you explain a little more about what you're trying to do?  It sounds like you want a protocol in which either client or the server initiates a remote procedure call.  The easiest way to do this is to have the client also be a server and the server also be a client.  For example, consider the following protocols:
>
> protocol WeatherClient {
>   double getTemperature(string postalCode);
>   void registerForTemperatureUpdates(string postalCode, string clientHost, int clientPort);
> }
>
> protocol WeatherUpdateListener {
>   void onTemperatureUpdate(String postalCode, double newTemperature);
> }
>
> The client side would use WeatherClient (and SpecificRequestor/NettyTransceiver) to request the temperature for some postal code from the server.  The client could also register with the server for temperature updates by passing the postal code it's interested in as well as the hostname/IP and port of a netty server running on the client.  The client would run its own netty server using a WeatherUpdateListener and SpecificResponder.  When the server has a temperature update to send back to the client, it would send a message to the client using the WeatherUpdateListener interface.  Is this close to what you're looking for?
>
> -James
>
>
>
> On Fri, Jan 20, 2012 at 6:34 AM, Armin Garcia <[EMAIL PROTECTED]> wrote:
> I am trying to figure out how a message can be sent through a Netty Server to a connected client.  I see the channel is stored in a group for each client that connects to a Netty Server:
>
> public void channelOpen(ChannelHandlerContext ctx, ChannelStateEvent e) throws Exception
> {
>      e.getChannel().write(null);
>      allChannels.add(e.getChannel());
>      super.channelOpen(ctx, e);
> }
>
> The challenge is how to leverage this channel in order to send an unsolicited message to the client.  Is there an example that writes to the channel but not as a response to a message received?  
>
> I fully expect to take the existing Netty Server and modify it.  I suspect the solution lies somewhere in creating a NettyDataPack then writing it to the channel.  I'm definitely an Avro  greenhorn, so I'm a bit unsure of how to wrangle my message into a NettyDataPack.
>
>            -Armin
>
>
>
>

Hi Shaun,

This is definitely another way.  I share your same concern.  I have to keep
an eye out for high availablilty and high throughput.  I'll be depending on
this connection to support a massive amount of data.

               -Armin

On Fri, Jan 20, 2012 at 9:25 AM, Shaun Williams <[EMAIL PROTECTED]>wrote:

> Another solution is to use the response leg of a transaction to push
> messages to the client, e.g. provide a server protocol like this:
>
> WeatherUpdate listenForUpdate();
>
> This would essentially block until an update is available.  The only
> problem is that if the client is expecting a series of updates, it would
> need to call this method again after receiving each update.
>
> This is not an ideal solution, but it might solve your problem.
>
> -Shaun
>
>
>
> On Jan 20, 2012, at 8:24 AM, Armin Garcia wrote:
>
> Hi James,
>
>
> First, thank you for your response.
>
>
> Yes, you are right.  I am trying to setup a bi-directional communication
> link.  Your suggestion would definitely accomplish this requirement.  I was
> hoping the same channel could be reused without having to establish another
> uni-directional link.  Netty or rather NIO is inherently bi-directional.  I
> am suspecting RPC by definition is only uni-directional or rather a pull
> technology?
>
>
> One of my goals is to support as many different language bindings using
> Avro.  PHP is one of those languages.  Unfortunately, the PHP library can
> only function as a client.
>
>
>                -Armin
>
> On Fri, Jan 20, 2012 at 7:47 AM, James Baldassari <[EMAIL PROTECTED]>wrote:
>
>> Hi Armin,
>>
>> Could you explain a little more about what you're trying to do?  It
>> sounds like you want a protocol in which either client or the server
>> initiates a remote procedure call.  The easiest way to do this is to have
>> the client also be a server and the server also be a client.  For example,
>> consider the following protocols:
>>
>> protocol WeatherClient {
>>   double getTemperature(string postalCode);
>>   void registerForTemperatureUpdates(string postalCode, string
>> clientHost, int clientPort);
>> }
>>
>> protocol WeatherUpdateListener {
>>   void onTemperatureUpdate(String postalCode, double newTemperature);
>> }
>>
>> The client side would use WeatherClient (and
>> SpecificRequestor/NettyTransceiver) to request the temperature for some
>> postal code from the server.  The client could also register with the
>> server for temperature updates by passing the postal code it's interested
>> in as well as the hostname/IP and port of a netty server running on the
>> client.  The client would run its own netty server using a
>> WeatherUpdateListener and SpecificResponder.  When the server has a
>> temperature update to send back to the client, it would send a message to
>> the client using the WeatherUpdateListener interface.  Is this close to
>> what you're looking for?
>>
>> -James
>>
>>
>>
>> On Fri, Jan 20, 2012 at 6:34 AM, Armin Garcia <[EMAIL PROTECTED]>wrote:
>>
>>> I am trying to figure out how a message can be sent through a Netty
>>> Server to a connected client.  I see the channel is stored in a group for
>>> each client that connects to a Netty Server:
>>>
>>> public void channelOpen(ChannelHandlerContext ctx, ChannelStateEvent e)
>>> throws Exception
>>> {
>>>      e.getChannel().write(null);
>>>      *allChannels.add(e.getChannel());*
>>>      super.channelOpen(ctx, e);
>>> }
>>>
>>> The challenge is how to leverage this channel in order to send an
>>> unsolicited message to the client.  Is there an example that writes to the
>>> channel but not as a response to a message received?
>>>
>>> I fully expect to take the existing Netty Server and modify it.  I
>>> suspect the solution lies somewhere in creating a NettyDataPack then
>>> writing it to the channel.  I'm definitely an Avro  greenhorn, so I'm a bit
>>> unsure of how to wrangle my message into a NettyDataPack.
>>>
>>>            -Armin
>>>
>>>
>>>
>>
>
>

Hi Armin,

First I'd like to explain why the server-initiated messages are
problematic.  Allowing the server to send unsolicited messages back to the
client may work for some Transceiver implementations (possibly PHP), but
this change would not be compatible with NettyTransceiver.  When the
NettyTransceiver receives a message from the server, it needs to know which
callback to invoke in order to pass the message back correctly to the
client.  There could be several RPCs "in flight" concurrently, so one of
NettyTransceiver's jobs is to match up the response with the request that
initiated it.  If the client didn't initiate the RPC then NettyTransceiver
won't know where to deliver the message, unless there were some catch-all
callback that would be invoked whenever one of these "unsolicited" messages
were received.  So although you're probably only interested in the PHP
client, allowing the server to send these unsolicited messages would
potentially break NettyTransceiver (and possibly other implementations as
well).

Shaun's idea of having the client poll the server periodically would
definitely work.  What we want to do is have the client receive
notifications from the server as they become available on the server side,
but we also don't want the client to be polling with such a high frequency
that a lot of CPU and bandwidth resources are wasted.  I think we can get
the best of both worlds by copying the Comet pattern, i.e. the "long poll"
but using the Avro RPC layer instead of (or on top of) HTTP.  First we'll
start with Shaun's update listener interface:

protocol WeatherUpdateListener {
  WeatherUpdate listenForUpdate();
}

The PHP client would invoke this RPC against the server in a tight loop.
On the server side, the RPC will block until there is an update that is
ready to be sent to the client.  When the client does receive an event from
the server (or some timeout occurs), the client will immediately send
another poll to the server and block until the next update is received.  In
this way the client will not be flooding the server with RPCs, but the
client will also get updates in a timely manner.

See the following for more info about Comet:
http://www.javaworld.com/javaworld/jw-03-2008/jw-03-asynchhttp.html?page=6

-James
On Fri, Jan 20, 2012 at 12:44 PM, Armin Garcia <[EMAIL PROTECTED]>wrote:

> Hi Shaun,
>
> This is definitely another way.  I share your same concern.  I have to
> keep an eye out for high availablilty and high throughput.  I'll be
> depending on this connection to support a massive amount of data.
>
>                -Armin
>
>
> On Fri, Jan 20, 2012 at 9:25 AM, Shaun Williams <[EMAIL PROTECTED]>wrote:
>
>> Another solution is to use the response leg of a transaction to push
>> messages to the client, e.g. provide a server protocol like this:
>>
>> WeatherUpdate listenForUpdate();
>>
>> This would essentially block until an update is available.  The only
>> problem is that if the client is expecting a series of updates, it would
>> need to call this method again after receiving each update.
>>
>> This is not an ideal solution, but it might solve your problem.
>>
>> -Shaun
>>
>>
>>
>> On Jan 20, 2012, at 8:24 AM, Armin Garcia wrote:
>>
>> Hi James,
>>
>>
>> First, thank you for your response.
>>
>>
>> Yes, you are right.  I am trying to setup a bi-directional communication
>> link.  Your suggestion would definitely accomplish this requirement.  I was
>> hoping the same channel could be reused without having to establish another
>> uni-directional link.  Netty or rather NIO is inherently bi-directional.  I
>> am suspecting RPC by definition is only uni-directional or rather a pull
>> technology?
>>
>>
>> One of my goals is to support as many different language bindings using
>> Avro.  PHP is one of those languages.  Unfortunately, the PHP library can
>> only function as a client.
>>
>>
>>                -Armin
>>
>> On Fri, Jan 20, 2012 at 7:47 AM, James Baldassari <[EMAIL PROTECTED]>wrote:

Hi James,

I see your point. On a different NIO framework, I implemented exactly the
same message handling procedure (ie message routing) you just described. I
guess I was pushing the NettyTransceiver a bit beyond its intended scope.

I'll take a look at the comet pattern and see what I can do with it.

Again, thanks Shaun & James.

    -Armin
On Fri, Jan 20, 2012 at 10:15 AM, James Baldassari <[EMAIL PROTECTED]>wrote:

> Hi Armin,
>
> First I'd like to explain why the server-initiated messages are
> problematic.  Allowing the server to send unsolicited messages back to the
> client may work for some Transceiver implementations (possibly PHP), but
> this change would not be compatible with NettyTransceiver.  When the
> NettyTransceiver receives a message from the server, it needs to know which
> callback to invoke in order to pass the message back correctly to the
> client.  There could be several RPCs "in flight" concurrently, so one of
> NettyTransceiver's jobs is to match up the response with the request that
> initiated it.  If the client didn't initiate the RPC then NettyTransceiver
> won't know where to deliver the message, unless there were some catch-all
> callback that would be invoked whenever one of these "unsolicited" messages
> were received.  So although you're probably only interested in the PHP
> client, allowing the server to send these unsolicited messages would
> potentially break NettyTransceiver (and possibly other implementations as
> well).
>
> Shaun's idea of having the client poll the server periodically would
> definitely work.  What we want to do is have the client receive
> notifications from the server as they become available on the server side,
> but we also don't want the client to be polling with such a high frequency
> that a lot of CPU and bandwidth resources are wasted.  I think we can get
> the best of both worlds by copying the Comet pattern, i.e. the "long poll"
> but using the Avro RPC layer instead of (or on top of) HTTP.  First we'll
> start with Shaun's update listener interface:
>
> protocol WeatherUpdateListener {
>   WeatherUpdate listenForUpdate();
> }
>
> The PHP client would invoke this RPC against the server in a tight loop.
> On the server side, the RPC will block until there is an update that is
> ready to be sent to the client.  When the client does receive an event from
> the server (or some timeout occurs), the client will immediately send
> another poll to the server and block until the next update is received.  In
> this way the client will not be flooding the server with RPCs, but the
> client will also get updates in a timely manner.
>
> See the following for more info about Comet:
> http://www.javaworld.com/javaworld/jw-03-2008/jw-03-asynchhttp.html?page=6
>
> -James
>
>
>
> On Fri, Jan 20, 2012 at 12:44 PM, Armin Garcia <[EMAIL PROTECTED]>wrote:
>
>> Hi Shaun,
>>
>> This is definitely another way.  I share your same concern.  I have to
>> keep an eye out for high availablilty and high throughput.  I'll be
>> depending on this connection to support a massive amount of data.
>>
>>                -Armin
>>
>>
>> On Fri, Jan 20, 2012 at 9:25 AM, Shaun Williams <[EMAIL PROTECTED]
>> > wrote:
>>
>>> Another solution is to use the response leg of a transaction to push
>>> messages to the client, e.g. provide a server protocol like this:
>>>
>>> WeatherUpdate listenForUpdate();
>>>
>>> This would essentially block until an update is available.  The only
>>> problem is that if the client is expecting a series of updates, it would
>>> need to call this method again after receiving each update.
>>>
>>> This is not an ideal solution, but it might solve your problem.
>>>
>>> -Shaun
>>>
>>>
>>>
>>> On Jan 20, 2012, at 8:24 AM, Armin Garcia wrote:
>>>
>>> Hi James,
>>>
>>>
>>> First, thank you for your response.
>>>
>>>
>>> Yes, you are right.  I am trying to setup a bi-directional communication
>>> link.  Your suggestion would definitely accomplish this requirement.  I was

For certain kinds of data it would be useful to continuously stream data
from server to client (or vice-versa).  This can be represented as an Avro
array response or request where each array element triggers a callback at
the receiving end.  This likely requires an extension to the avro spec, but
is much more capable than a polling solution.  It is related to Comet in the
sense that the RPC request is long lived, but is effectively a sequence of
smaller inverse RPCs.  Poling in general has built-in race conditions for
many types of information exchange and should be avoided whenever such race
conditions exist.

For streaming large volumes of data, this would be much more efficient than
an individual RPC per item.  For example, if the RPC is "I need to know
every state change in X" polling is not an option, but streaming is.  If the
requirement is "I need to know when the next state change occurs, but do not
need to know all changes" polling is OK, and streaming may send too much
data.

On 1/20/12 11:25 AM, "Armin Garcia" <[EMAIL PROTECTED]> wrote:

> Hi James,
>
> I see your point. On a different NIO framework, I implemented exactly the same
> message handling procedure (ie message routing) you just described. I guess I
> was pushing the NettyTransceiver a bit beyond its intended scope.
>
> I'll take a look at the comet pattern and see what I can do with it.
>
> Again, thanks Shaun & James.
>
>     -Armin
>
>
> On Fri, Jan 20, 2012 at 10:15 AM, James Baldassari <[EMAIL PROTECTED]>
> wrote:
>> Hi Armin,
>>
>> First I'd like to explain why the server-initiated messages are problematic.
>> Allowing the server to send unsolicited messages back to the client may work
>> for some Transceiver implementations (possibly PHP), but this change would
>> not be compatible with NettyTransceiver.  When the NettyTransceiver receives
>> a message from the server, it needs to know which callback to invoke in order
>> to pass the message back correctly to the client.  There could be several
>> RPCs "in flight" concurrently, so one of NettyTransceiver's jobs is to match
>> up the response with the request that initiated it.  If the client didn't
>> initiate the RPC then NettyTransceiver won't know where to deliver the
>> message, unless there were some catch-all callback that would be invoked
>> whenever one of these "unsolicited" messages were received.  So although
>> you're probably only interested in the PHP client, allowing the server to
>> send these unsolicited messages would potentially break NettyTransceiver (and
>> possibly other implementations as well).
>>
>> Shaun's idea of having the client poll the server periodically would
>> definitely work.  What we want to do is have the client receive notifications
>> from the server as they become available on the server side, but we also
>> don't want the client to be polling with such a high frequency that a lot of
>> CPU and bandwidth resources are wasted.  I think we can get the best of both
>> worlds by copying the Comet pattern, i.e. the "long poll" but using the Avro
>> RPC layer instead of (or on top of) HTTP.  First we'll start with Shaun's
>> update listener interface:
>>
>> protocol WeatherUpdateListener {
>>   WeatherUpdate listenForUpdate();
>> }
>>
>> The PHP client would invoke this RPC against the server in a tight loop.  On
>> the server side, the RPC will block until there is an update that is ready to
>> be sent to the client.  When the client does receive an event from the server
>> (or some timeout occurs), the client will immediately send another poll to
>> the server and block until the next update is received.  In this way the
>> client will not be flooding the server with RPCs, but the client will also
>> get updates in a timely manner.
>>
>> See the following for more info about Comet:
>> http://www.javaworld.com/javaworld/jw-03-2008/jw-03-asynchhttp.html?page=6
>>
>> -James
>>
>>
>>
>> On Fri, Jan 20, 2012 at 12:44 PM, Armin Garcia <[EMAIL PROTECTED]>

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

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