users@grizzly.java.net

Re: Protocol type inside ProtocolParser

From: Tigran Mkrtchyan <tigran.mkrtchyan_at_desy.de>
Date: Tue, 29 Sep 2009 21:38:56 +0200

Hi Alexey,

first of all I want to share my solution:

public class ProtocolKeeperFilter implements ProtocolFilter {

     public static final String CONNECTION_PROTOCOL = "ConnectionProtocol";

     public boolean execute(Context cntxt) throws IOException {
         Controller.Protocol protocol = cntxt.getProtocol();
         ((WorkerThread)Thread.currentThread()).getAttachment().setAttribute(CONNECTION_PROTOCOL, protocol);
         return true;
     }

     public boolean postExecute(Context cntxt) throws IOException {
         ((WorkerThread)Thread.currentThread()).getAttachment().removeAttribute(CONNECTION_PROTOCOL);
         return true;
     }

}

The filter is the first one.

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.

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
>