Protocol type inside ProtocolParser

[Tigran Mkrtchyan-3]

Hi,

short question: how can I distinguish between TCP and UDP inside protocolParser?

Thanks,
        Tigran.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jeanfrancois Arcand-2]

Salut,

Tigran Mkrtchyan wrote:
>
> 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.
(2) Inside the newProtocolParser(), retrieve that value.

Does that help?

A+
-- Jeanfrancois
>
> Thanks,
>     Tigran.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Tigran Mkrtchyan-3]

On 09/28/2009 09:44 PM, Jeanfrancois Arcand wrote:

> Salut,
>
> Tigran Mkrtchyan wrote:
>>
>> 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.


Regards,
        Tigran.

> (2) Inside the newProtocolParser(), retrieve that value.
>
> Does that help?
>
> A+
> -- Jeanfrancois
>>
>> Thanks,
>> Tigran.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jeanfrancois Arcand-2]

Salut,

Tigran Mkrtchyan wrote:

>
>
> On 09/28/2009 09:44 PM, Jeanfrancois Arcand wrote:
>> Salut,
>>
>> Tigran Mkrtchyan wrote:
>>>
>>> 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?

A+

- Jeanfrancois

>
>
> Regards,
>     Tigran.
>> (2) Inside the newProtocolParser(), retrieve that value.
>>
>> Does that help?
>>
>> A+
>> -- Jeanfrancois
>>>
>>> Thanks,
>>> Tigran.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Oleksiy Stashok]

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@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Tigran Mkrtchyan-3]

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@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Oleksiy Stashok]

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@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Tigran Mkrtchyan-3]

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@...
>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Oleksiy Stashok]

>>> 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@...
>>>>>>>> For additional commands, e-mail: users-
>>>>>>>> help@...
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...