>>> 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 :).
I just wanted to recheck that :))
> The additional filter forks fine.
> While I am the only one who needs it there is no
> reason to change praser interface.
Right, the main goal for parser is to convert ByteBuffer to some
custom representation, so Context is not directly related to this
process, though I agree, we can consider Parser API change, if it's
required.
WBR,
Alexey.
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>