users@grizzly.java.net

Re: Protocol type inside ProtocolParser

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Wed, 30 Sep 2009 10:20:53 +0200

Hi Tigran,

> Why I need it:
>
> I am wring an RPC based server and client and as a result have to
> implement
> rpc protocol parser based on rfc1831. The RPC protocol has different
> semantic
> for UDP and TCP based packes: in TCP based records first integer is
> a length of the
> record + boolean 'end-of-message'. UDP does not have it. This forces
> me to know
> inside the parser what is the current protocol.I am using the both
> protocols at
> the same time:
>
> final TCPSelectorHandler tcpHandler = new TCPSelectorHandler();
> tcpHandler.setPort(port);
> _controller.addSelectorHandler(tcpHandler);
>
> final UDPSelectorHandler udpHandler = new UDPSelectorHandler();
> udpHandler.setPort(port);
> _controller.addSelectorHandler(udpHandler);
>
> Of course I want to use single parser for bough.
I got your point. Just small question, if you have some difference
parsing messages coming from TCP and UDP transports, doesn't it make
sense to have something like:

                BaseParser
                  / \
  TCPParser UDPParser

And create separate filterchains for different transports?

Anyway, I'm pretty sure your solution with additional Filter will work
fine.

Thanks.

WBR,
Alexey.


>
> Regards,
> Tigran.
>
> P.S: Grizzly is cool! Nevertheless, you need a better documentation
> - kind of cook ( with WORKING examples ).
>
> On 09/29/2009 04:43 PM, Oleksiy Stashok wrote:
>> Hi,
>>
>>>>>> Hi,
>>>>>>
>>>>>> short question: how can I distinguish between TCP and UDP inside
>>>>>> protocolParser?
>>>>>
>>>>> Interesting question. I think the easiest way is to:
>>>>>
>>>>> (1) override public boolean execute(Context ctx) from
>>>>> ParserProtocolFilter and locally store the result of
>>>>> ctx.getProtocol()
>>>>> as WorkerThread.getAttachement().setAttribute(...) or a
>>>>> ThreadLocal.
>>>> Oh, I can simply add yet another filter in the chain which will
>>>> do it.
>>>> Sound's like interface breaking, I think you need to propagate it
>>>> down to parser.
>>>
>>> I agree. Except it's the first time we are getting the request so it
>>> may be difficult to change that API. What others thinks?
>> As I understand the issue here - is to pass Context to Parser.
>> Tigran,
>> can you pls. elaborate a little bit why you might need that?
>>
>> Thanks.
>>
>> WBR,
>> Alexey.
>>
>>>
>>> A+
>>>
>>> - Jeanfrancois
>>>
>>>> Regards,
>>>> Tigran.
>>>>> (2) Inside the newProtocolParser(), retrieve that value.
>>>>>
>>>>> Does that help?
>>>>>
>>>>> A+
>>>>> -- Jeanfrancois
>>>>>>
>>>>>> Thanks,
>>>>>> Tigran.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>