mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [MINA 3.0] filter chains
Date Fri, 26 Aug 2011 16:19:03 GMT
On 8/26/11 6:15 PM, Julien Vermillard wrote:
> On Fri, Aug 26, 2011 at 6:10 PM, Emmanuel Lecharny<elecharny@gmail.com>  wrote:
>> On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
>>> On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
>>>
>>>> On 8/26/11 4:55 PM, Alan D. Cabrera wrote:
>>>>> On Aug 26, 2011, at 7:47 AM, Emmanuel Lecharny wrote:
>>>>>
>>>>>> On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
>>>>>>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>>>>>>
>>>>>>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel
>>>>>>>> Lecharny<elecharny@gmail.com>      wrote:
>>>>>>>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>>>>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>>>>>>>
>>>>>>>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D.
>>>>>>>>>>> Cabrera<list@toolazydogs.com>
>>>>>>>>>>>   wrote:
>>>>>>>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard
wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I modified the API to remove IoFilterChain.
Now you are supposed
>>>>>>>>>>>>> to
>>>>>>>>>>>>> give a list of filter to the service
before starting it :
>>>>>>>>>>>>>
>>>>>>>>>>>>> // create the fitler chain for this service
>>>>>>>>>>>>> List<IoFilter>       filters =
new ArrayList<IoFilter>();
>>>>>>>>>>>>> filters.add(new LoggingFilter("byte log
filter"));
>>>>>>>>>>>>> filters.add(new MyCodecFilter());
>>>>>>>>>>>>> filters.add(new LoggingFilter("pojo log
filter"));
>>>>>>>>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>>>>>>>>>
>>>>>>>>>>>>> acceptor.setFilters(filters);
>>>>>>>>>>>>>
>>>>>>>>>>>>> acceptor.bind(...);
>>>>>>>>>>>> How do we make chains where two filters feed
into one or one
>>>>>>>>>>>> filter
>>>>>>>>>>>> feeds two filters?  If you look in my sandbox
we can accommodate
>>>>>>>>>>>> this via:
>>>>>>>>>>>>
>>>>>>>>>>>> static import a.m.util.Util. linkParentWithChild;
// to be
>>>>>>>>>>>> written
>>>>>>>>>>>>
>>>>>>>>>>>> IoFilter foo = new FooFilter();
>>>>>>>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>>>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>>>>>>>> IoFilter log = new LogFilter();
>>>>>>>>>>>>
>>>>>>>>>>>> link.addLinkStateListener(foo);
>>>>>>>>>>>> linkParentWithChild(foo, checksum);
>>>>>>>>>>>> linkParentWithChild(link, checksum);
>>>>>>>>>>>> linkParentWithChild(checksum, log);
>>>>>>>>>>>>
>>>>>>>>>>>> acceptor.setFilters(foo);
>>>>>>>>>>>>
>>>>>>>>>>> About the code in the sandbox :
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>>>>>>>> I see no IoFilter.addLinkStateListener(..) method,
am I looking at
>>>>>>>>>>> the
>>>>>>>>>>> right place ?
>>>>>>>>>> Oops, it was meant to just be a sketch.  :)
>>>>>>>>>>
>>>>>>>>>>> About the "filters feed into one or one filter
feeds two filters",
>>>>>>>>>>> do
>>>>>>>>>>> you have a concrete use case in mind for that
?
>>>>>>>>>> The above example does, Foo and the link state filter.
 I'm sure
>>>>>>>>>> that
>>>>>>>>>> we've discussed this before.  Another example is
a mux/demux
>>>>>>>>>> situation.  How
>>>>>>>>>> would all of this fit into the grand scheme of things?
>>>>>>>>> Yeah, it really should be a graph of filters, not a list
of filters.
>>>>>>>>>
>>>>>>>> Well if it's just for demuxing I proposed few mails ago this
solution
>>>>>>>> : http://s.apache.org/A9W
>>>>>>> I think we need to make graphing a 1st class citizen and not
buried
>>>>>>> inside another filter class.
>>>>>> I do agree. The proposed solution on http://s.apache.org/A9W is what
we
>>>>>> currently have, and it's tedious to manage.
>>>>>>
>>>>>> It would be way better to be able to let the controler call the next
>>>>>> filter based on an evaluation method based on the current state.
>>>>>>
>>>>>>
>>>>>> Now, the question is : how do the controller knows which filter to
call
>>>>>> next ? It must have the current state, and it must be able to make
the
>>>>>> connection.
>>>>>>
>>>>>> For instance, let's say that from filter F we can switch to either
>>>>>> filter G or filter H, depending on the state we transit to in F.
>>>>>>
>>>>>> F --(state1)-->     G
>>>>>> or
>>>>>> F --(state2)-->     H
>>>>>>
>>>>>> That means the controller has a map { (F, state1, G), (F, state2,
H)}
>>>>>> somewhere. State should be passed to the controller too :
>>>>>>
>>>>>> ...
>>>>>> controller.nextFilter( newState );
>>>>>> ...
>>>>>>
>>>>>> Pretty theorical at this point... I'm sorry not to have a lot of
time
>>>>>> to code this, I do realize that for you guys implementing ideas it's
a
>>>>>> PITA...
>>>>> I was thinking of a simple DAG some, or all, of the nodes can be FSMs.
>>>>>
>>>>> ->     [FSM1] ->     [Filter] ->     [FSM2] ->     [Filter]
>>>>>
>>>>> Inside the FSM there could be chains, but there would be one chain per
>>>>> state.
>>>> Not sure I grok what you say here. There is more than one state, and from
>>>> each state, you may have more than one transition.
>>>>
>>>> Maybe it's just a problem of vocabulary...
>>>>
>>>> <theory>
>>>> In a FSM, you transit from Si to Sj, following a transition Ta, which
>>>> depends on a context. You may also transit to a state Sk, following a
>>>> different transition Tb, if the context is different.
>>>>
>>>> Selection the transition to follow is all about knowing what's the
>>>> context is, and in my sample, this was what I call the 'state', which was
>>>> most certainly an error, as it's clearly a transition. I should have wrote
:
>>>>
>>>> F --(transition1)-->     G
>>>> or
>>>> F --(transition2)-->     H
>>>>
>>>> where F, G, H are filters (ore "states")
>>>>
>>>> are we on the same page ?
>>>>
>>>> </theory>
>>> Not at all.  :)
>>>
>>> Are F, G, H filters inside the FSM or are they external to the FSM?
>> They are filters in the FSM.
>>
> Until your minds are clear about where to go about muxing,FSM and
> filters I'll continue low-level implementation of MINA 3.0. The actual
> filter chain is enough for me to do protocol implementation and perf
> testing the NIO loops.

Go ahead. The fact that we are brain-storming about some additional 
feature should not stop you to build some good base we can butcher later :)


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message