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