users@grizzly.java.net

Re: Protocol type inside ProtocolParser

From: Tigran Mkrtchyan <tigran.mkrtchyan_at_desy.de>
Date: Wed, 30 Sep 2009 11:54:39 +0200

On 09/30/09 10:20 AM, Oleksiy Stashok wrote:
> 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

that is excely what I want to avoid :).
The additional filter forks fine.
While I am the only one who needs it there is no
reason to change praser interface.

Tigran.

>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>