You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Edouard De Oliveira <do...@yahoo.fr> on 2011/08/25 14:29:13 UTC
Re : Re : [MINA 3.0] filter chains
On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira
<do...@yahoo.fr> wrote:
>
>
> On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
>> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
>>
>>
>>> But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate a much more complicated FSM that the coder would have to describe with code ... better ?) ?
>>>
>>> Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ?
>>
>> There's no reason why one could not have a chain of FSMs. You get the exact same behavior with less framework code.
>
>>The reason why MINA 1 and 2 has a chain is unclear. One possible explainaition is that MINA was supposed to implement the SEDA >architecture (each filter communicate with the next filter using a queue, and as this architecture is supposed to spread filters on more than >one computer, then it's easier to implement it using a chain. Well, that's my perception. One other reason was the lack of vision about the >possible use cases. 6 years in restrospect, I do think that this need never surfaced...
> With the growing of the base code it's easier just by looking at what exists to find some use case one would not have though of at this time
>
>>The more I think about this problem, the more I think that FSM is the way to go :
>>- we don't add filters dynamically on a created session
>
>
>>- we *always* know which filter we will call whatever state we are : it's a protocol we are handling, it's well defined !
> +1 : it's just that it will require much more preliminary toughts to start coding a server -> that's our good practices promoting thing
>
>>- debugging will be easier
> i won't be so categorical about this as whatever graph type you use to describe your 'chain' it will still be session/data dependent
>
>>- we won't have to use some strange Mutiplexer filter in order to call one filter or another depending on the message we are dealing with, like >it's currently the case in MINA 2
> not so strange as it is a well known design pattern (Command Pattern)
>
>>- coding a protocol will be easier
> we have to make basic servers easier (or as easy as before) too
>
>>- we can define @ to declare the FSM, making the developper's life easier (an idea that needs to be developed...)
>
>>i was also planning on some @ (like @unique to limit the presence of a filter in the chain or some more generic one that would provide the name and the unicity of the filter for Mina 2 obviously)
>
>>for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated FSM declaration code and found this interesting article >which could be a good base to start with :
>>http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html
>
>
> You can find a fast hack at the following pastebin url which shows how i changed the original code of the article to add data dependent transitions :
> http://pastebin.com/CjXjJ2Q1
>
>
>>Do we all agree on that ?
>>There's lot of momentum on this solution so it should be given at least a try obviously
>
>+1
>it's hard for me to figure if it's going to be the solution witout a
>more complex example implementation
it's far from being an implementation it's just a basic poc that a fsm can be built with @
Re: Re : Re : [MINA 3.0] filter chains
Posted by Julien Vermillard <jv...@gmail.com>.
On Fri, Aug 26, 2011 at 1:23 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> On 8/26/11 1:14 PM, Julien Vermillard wrote:
>>
>> On Thu, Aug 25, 2011 at 2:29 PM, Edouard De Oliveira
>> <do...@yahoo.fr> wrote:
>>>
>>> On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira
>>>
>>> <do...@yahoo.fr> wrote:
>>>>
>>>> On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
>>>>>
>>>>> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
>>>>>
>>>>>
>>>>>> But i'm feeling more and more confused by the fsm need : as you said
>>>>>> some management bits in the session can switch on/off some filters why do we
>>>>>> want to complicate the coder 's life using a two state FSM (in the case of
>>>>>> multiple filters it would generate a much more complicated FSM that the
>>>>>> coder would have to describe with code ... better ?) ?
>>>>>>
>>>>>> Do you want the fsm to control the flow between filters (state=filter
>>>>>> ?) or do you want your fsm to control if a filter is active ?
>>>>>
>>>>> There's no reason why one could not have a chain of FSMs. You get the
>>>>> exact same behavior with less framework code.
>>>>> The reason why MINA 1 and 2 has a chain is unclear. One possible
>>>>> explainaition is that MINA was supposed to implement the SEDA>architecture
>>>>> (each filter communicate with the next filter using a queue, and as this
>>>>> architecture is supposed to spread filters on more than>one computer, then
>>>>> it's easier to implement it using a chain. Well, that's my perception. One
>>>>> other reason was the lack of vision about the>possible use cases. 6 years in
>>>>> restrospect, I do think that this need never surfaced...
>>>>
>>>> With the growing of the base code it's easier just by looking at what
>>>> exists to find some use case one would not have though of at this time
>>>>
>>>>> The more I think about this problem, the more I think that FSM is the
>>>>> way to go :
>>>>> - we don't add filters dynamically on a created session
>>>>
>>>>> - we *always* know which filter we will call whatever state we are :
>>>>> it's a protocol we are handling, it's well defined !
>>>>
>>>> +1 : it's just that it will require much more preliminary toughts to
>>>> start coding a server -> that's our good practices promoting thing
>>>>
>>>>> - debugging will be easier
>>>>
>>>> i won't be so categorical about this as whatever graph type you use to
>>>> describe your 'chain' it will still be session/data dependent
>>>>
>>>>> - we won't have to use some strange Mutiplexer filter in order to call
>>>>> one filter or another depending on the message we are dealing with,
>>>>> like>it's currently the case in MINA 2
>>>>
>>>> not so strange as it is a well known design pattern (Command Pattern)
>>>>
>>>>> - coding a protocol will be easier
>>>>
>>>> we have to make basic servers easier (or as easy as before) too
>>>>
>>>>> - we can define @ to declare the FSM, making the developper's life
>>>>> easier (an idea that needs to be developed...)
>>>>> i was also planning on some @ (like @unique to limit the presence of a
>>>>> filter in the chain or some more generic one that would provide the name and
>>>>> the unicity of the filter for Mina 2 obviously)
>>>>> for mina 3 i indeed was wondering if somehow we could use @ to prevent
>>>>> bloated FSM declaration code and found this interesting article>which could
>>>>> be a good base to start with :
>>>>>
>>>>> http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html
>>>>
>>>> You can find a fast hack at the following pastebin url which shows how i
>>>> changed the original code of the article to add data dependent transitions :
>>>> http://pastebin.com/CjXjJ2Q1
>>>>
>>>>
>>>>> Do we all agree on that ?
>>>>> There's lot of momentum on this solution so it should be given at least
>>>>> a try obviously
>>>>
>>>> +1
>>>> it's hard for me to figure if it's going to be the solution witout a
>>>> more complex example implementation
>>>
>>> it's far from being an implementation it's just a basic poc that a fsm
>>> can be built with @
>>>
>>>
>> 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);
>
> I would like to have something like :
>
> acceptor.addFilters(
> new LoggingFilter("byte log filter"),
> new MyCodecFilter(),
> new LoggingFilter("pojo log filter"),
> newMyProtocolLogicFilter() )
>
> which is easy as soon as we have a Acceptor.addFilters( Filter... filters )
> method. (ellipsis notation is really very comfy)
>
> thoughts ?
>
> Otherwise, I'm fine with your approach.
>
Ok, I'll change it for varargs
Re: Re : Re : [MINA 3.0] filter chains
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 8/26/11 1:14 PM, Julien Vermillard wrote:
> On Thu, Aug 25, 2011 at 2:29 PM, Edouard De Oliveira
> <do...@yahoo.fr> wrote:
>> On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira
>>
>> <do...@yahoo.fr> wrote:
>>>
>>> On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
>>>> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
>>>>
>>>>
>>>>> But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate a much more complicated FSM that the coder would have to describe with code ... better ?) ?
>>>>>
>>>>> Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ?
>>>> There's no reason why one could not have a chain of FSMs. You get the exact same behavior with less framework code.
>>>> The reason why MINA 1 and 2 has a chain is unclear. One possible explainaition is that MINA was supposed to implement the SEDA>architecture (each filter communicate with the next filter using a queue, and as this architecture is supposed to spread filters on more than>one computer, then it's easier to implement it using a chain. Well, that's my perception. One other reason was the lack of vision about the>possible use cases. 6 years in restrospect, I do think that this need never surfaced...
>>> With the growing of the base code it's easier just by looking at what exists to find some use case one would not have though of at this time
>>>
>>>> The more I think about this problem, the more I think that FSM is the way to go :
>>>> - we don't add filters dynamically on a created session
>>>
>>>> - we *always* know which filter we will call whatever state we are : it's a protocol we are handling, it's well defined !
>>> +1 : it's just that it will require much more preliminary toughts to start coding a server -> that's our good practices promoting thing
>>>
>>>> - debugging will be easier
>>> i won't be so categorical about this as whatever graph type you use to describe your 'chain' it will still be session/data dependent
>>>
>>>> - we won't have to use some strange Mutiplexer filter in order to call one filter or another depending on the message we are dealing with, like>it's currently the case in MINA 2
>>> not so strange as it is a well known design pattern (Command Pattern)
>>>
>>>> - coding a protocol will be easier
>>> we have to make basic servers easier (or as easy as before) too
>>>
>>>> - we can define @ to declare the FSM, making the developper's life easier (an idea that needs to be developed...)
>>>> i was also planning on some @ (like @unique to limit the presence of a filter in the chain or some more generic one that would provide the name and the unicity of the filter for Mina 2 obviously)
>>>> for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated FSM declaration code and found this interesting article>which could be a good base to start with :
>>>> http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html
>>>
>>> You can find a fast hack at the following pastebin url which shows how i changed the original code of the article to add data dependent transitions :
>>> http://pastebin.com/CjXjJ2Q1
>>>
>>>
>>>> Do we all agree on that ?
>>>> There's lot of momentum on this solution so it should be given at least a try obviously
>>> +1
>>> it's hard for me to figure if it's going to be the solution witout a
>>> more complex example implementation
>>
>> it's far from being an implementation it's just a basic poc that a fsm can be built with @
>>
>>
> 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);
I would like to have something like :
acceptor.addFilters(
new LoggingFilter("byte log filter"),
new MyCodecFilter(),
new LoggingFilter("pojo log filter"),
newMyProtocolLogicFilter() )
which is easy as soon as we have a Acceptor.addFilters( Filter...
filters ) method. (ellipsis notation is really very comfy)
thoughts ?
Otherwise, I'm fine with your approach.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
Posted by Emmanuel Lécharny <el...@apache.org>.
On 8/27/11 10:53 AM, Alex Karasulu wrote:
> On Sat, Aug 27, 2011 at 5:35 AM, Emmanuel Lecharny<el...@gmail.com>wrote:
>
>> On 8/27/11 2:04 AM, Alan D. Cabrera wrote:
>>
>>> On Aug 26, 2011, at 1:27 PM, Emmanuel Lecharny wrote:
>>>
>>> On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
>>>>> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>>>>>
>>>>> On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
>>>>>>> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
>>>>>>> What I have in mind is much more something like :
>>>>>>>
>>>>>>> void messageReceived( context )
>>>>>>> {
>>>>>>> ... // do something, updating the context, eventually setting a
>>>>>>> status
>>>>>>> controller.callNextFilter( context, currentFilter );
>>>>>>> ... // do something after the call
>>>>>>> }
>>>>>>>
>>>>>>> and in controller :
>>>>>>> void callNextFilter( Context context, Filter currentFilter )
>>>>>>> {
>>>>>>> Status status = context.getStatus();
>>>>>>> Map<Status, Filter> map = fsmMap.get( currentFilter );
>>>>>>> Filter nextFilter = map.get( status );
>>>>>>>
>>>>>>> nextFilter.messageReceived( context );
>>>>>>> }
>>>>>>> This strikes me as pretty complex, jmho. Also, I don't like the idea
>>>>>>> of forcing the filter to call the controller.callNextFilter() to make things
>>>>>>> work.
>>>>>>>
>>>>>> the alternative would be something like :
>>>>>>
>>>>>> void messageReceived( context )
>>>>>> {
>>>>>> ... // do something, updating the context, eventually setting a
>>>>>> status
>>>>>> fsmMap.get( this ).get( status ).messageReceived( context );
>>>>>> ... // do something after the call
>>>>>> }
>>>>>>
>>>>>> No controller, but a long list of chained call.
>>>>>>
>>>>> But we're still forcing the filter to participate in things that really
>>>>> should be the domain of the controller not the filter.
>>>>>
>>>> If we delegate the transition to the controller, then we can't have post
>>>> actions... Obviously, not having post actions makes it easier. (Post action
>>>> are really important if we want to do something when we come back from the
>>>> application.)
>>>>
>>> I think we're getting to some interesting bits. Can you provide more exact
>>> detail?
>>>
>> One very simple example, taken from the ProfilerFilter :
>>
>> @Override
>> public void messageReceived(NextFilter nextFilter, IoSession session,
>> Object message) throws Exception {
>> if (profileMessageReceived) {
>> long start = timeNow();
>> nextFilter.messageReceived(**session, message);
>> long end = timeNow();
>> messageReceivedTimerWorker.**addNewDuration(end - start);
>> } else {
>> nextFilter.messageReceived(**session, message);
>> }
>> }
>>
>> If you depend on the controller to call thenext filter, then you have no
>> easy way to compute the time it takes to process the action, as you won't be
>> able to execute the post action.
>>
>> Note that the decoding of multiple messages within one PDU won't be
>> possible either without being able to process post-actions. (see below)
>>
>> One clear exemple would be a decoder processing a PDU with more than one
>>>> message : you can't anymore loop on the PDU if you delegate the next call to
>>>> the controller.
>>>>
>>> What is the format of this PDU and how is it presented to the FSM, i.e. in
>>> what kind of pieces does it arrive?
>>>
>> You get an array of bytes, containing potentially more than one message.
>> The fact is that you have no way to get a byte array from the socket as soon
>> as a complete message has been received : the socket does not know anything
>> about messages.
>>
>> You just have to assume that the PDU you've got can be :
>> - either a portion of a message, and you have to wait for more bytes in
>> order to produce a message
>> - a full message, once decoded
>> - more than one message you have to send to the handler one by one
>> - some full messages plus a fraction of a message
>>
>>
>>> With that said I think that an FSM where we have, here letters are
>>>>> filters:
>>>>>
>>>>> [outside filter] -> {A -> [state change decides to send to] -> B
>>>>> -> [state change decides to send to] -> C} -> [outside filter]
>>>>>
>>>>> is very confusing. What protocol would require that? Just an honest
>>>>> question; one does not come to my mind atm.
>>>>>
>>>> all of them :) This is what we currently do in MINA.
>>>>
>>> I think that I am hearing a reply that explains that all the protocols are
>>> implemented in this way. I'm not hearing an explanation as to why it *must*
>>> be that way.
>>>
>> simply because you can't move to the next filter unless you have
>> transformed what you've got from the previous filter. If we exclude all the
>> utility filters (like the loggers), a filter can only process a certain type
>> of message, and produce another type of message. The chain of filters is
>> dictated by the transformation done at each step. One good example is LDAP
>> processing : in order to decode a LDAP message, you first have to decode the
>> TLVs, then you can decode the messages themselves. A LDAP chain would be
>> something like :
>>
>> [outside filter] -> (bytes) -> { TLV decoder filter -> (TLVs) -> LDAP
>> decoder filter -> (LDAPmessages) } -> [outside filter]
>>
>> (add to this the fact that you may loop on the TLV filter *and* the LDAP
>> filter, plus the fact that you may have to wait for more bytes)
>>
>> Now, it makes *no sense* to exchange the filters. It will simply not work.
>> It's the very same for any protocol we will process with such a mechanism.
>>
>> In other words, the order the filters are executed is not random. It's
>> fixed by design, and does not change (as soon as we have ruled out the
>> possibility to have a dynamic chain).
>>
>>
>> Another way to see this mechanism is that it's a path from one point to
>> another : you may have many different paths, but for a set of bytes, you
>> will always follow the same path. The only way to follow two different paths
>> is when you get two different sets of bytes.
>>
>>
> Emmanuel, thanks for chiming in here on behalf of the ASN.1 based codecs.
> Alan these concepts are very important for us to factor in.
>
> The problem here is that processing in one state of an FSM may alter the
> control flow.
>
> I know we're trying to find the design that leads to the sweetest and
> easiest code for implementing these filters. However it's possible that this
> process of defining protocols may evolve to where protocol implementors feed
> in a state transition matrix and most of the code is generated minus
> customizations supplied for actions to take.
>
> I might be flying in the clouds with this but it might be another one of the
> design constraints added to Emmanuel's list to at least consider.
>
After having thought about FSM all night long, I realize this morning
that using a FSM and having post processing actions is a bit complex.
Assuming we let the controller deal with the transition from two states,
then that mean a post action must itself be a State (Filter).
Such a method :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a
status
fsmMap.get( this ).get( status ).messageReceived( context );
... // do something after the call
}
would have to be mapped differently :
Filter 1 :
void messageReceived( context )
{
... // do something
// End of the method, the control switch to the next configured filter
}
Filter2 (contain the post action)
void messageReceived( context )
{
... // do something, this is a post action
}
then the FSM should describe the following transition :
input ... -> Filter1.messageReceived() ---> handler.messageReceived()
--> Filter2.messageReceived()
So the post action is called when the handler has processed the message.
IMHO, it's not really convenient...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
Posted by Alex Karasulu <ak...@apache.org>.
On Sat, Aug 27, 2011 at 5:35 AM, Emmanuel Lecharny <el...@gmail.com>wrote:
> On 8/27/11 2:04 AM, Alan D. Cabrera wrote:
>
>> On Aug 26, 2011, at 1:27 PM, Emmanuel Lecharny wrote:
>>
>> On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
>>>
>>>> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>>>>
>>>> On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
>>>>>
>>>>>> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
>>>>>> What I have in mind is much more something like :
>>>>>>
>>>>>> void messageReceived( context )
>>>>>> {
>>>>>> ... // do something, updating the context, eventually setting a
>>>>>> status
>>>>>> controller.callNextFilter( context, currentFilter );
>>>>>> ... // do something after the call
>>>>>> }
>>>>>>
>>>>>> and in controller :
>>>>>> void callNextFilter( Context context, Filter currentFilter )
>>>>>> {
>>>>>> Status status = context.getStatus();
>>>>>> Map<Status, Filter> map = fsmMap.get( currentFilter );
>>>>>> Filter nextFilter = map.get( status );
>>>>>>
>>>>>> nextFilter.messageReceived( context );
>>>>>> }
>>>>>> This strikes me as pretty complex, jmho. Also, I don't like the idea
>>>>>> of forcing the filter to call the controller.callNextFilter() to make things
>>>>>> work.
>>>>>>
>>>>> the alternative would be something like :
>>>>>
>>>>> void messageReceived( context )
>>>>> {
>>>>> ... // do something, updating the context, eventually setting a
>>>>> status
>>>>> fsmMap.get( this ).get( status ).messageReceived( context );
>>>>> ... // do something after the call
>>>>> }
>>>>>
>>>>> No controller, but a long list of chained call.
>>>>>
>>>> But we're still forcing the filter to participate in things that really
>>>> should be the domain of the controller not the filter.
>>>>
>>> If we delegate the transition to the controller, then we can't have post
>>> actions... Obviously, not having post actions makes it easier. (Post action
>>> are really important if we want to do something when we come back from the
>>> application.)
>>>
>> I think we're getting to some interesting bits. Can you provide more exact
>> detail?
>>
>
> One very simple example, taken from the ProfilerFilter :
>
> @Override
> public void messageReceived(NextFilter nextFilter, IoSession session,
> Object message) throws Exception {
> if (profileMessageReceived) {
> long start = timeNow();
> nextFilter.messageReceived(**session, message);
> long end = timeNow();
> messageReceivedTimerWorker.**addNewDuration(end - start);
> } else {
> nextFilter.messageReceived(**session, message);
> }
> }
>
> If you depend on the controller to call thenext filter, then you have no
> easy way to compute the time it takes to process the action, as you won't be
> able to execute the post action.
>
> Note that the decoding of multiple messages within one PDU won't be
> possible either without being able to process post-actions. (see below)
>
> One clear exemple would be a decoder processing a PDU with more than one
>>> message : you can't anymore loop on the PDU if you delegate the next call to
>>> the controller.
>>>
>> What is the format of this PDU and how is it presented to the FSM, i.e. in
>> what kind of pieces does it arrive?
>>
>
> You get an array of bytes, containing potentially more than one message.
> The fact is that you have no way to get a byte array from the socket as soon
> as a complete message has been received : the socket does not know anything
> about messages.
>
> You just have to assume that the PDU you've got can be :
> - either a portion of a message, and you have to wait for more bytes in
> order to produce a message
> - a full message, once decoded
> - more than one message you have to send to the handler one by one
> - some full messages plus a fraction of a message
>
>
>> With that said I think that an FSM where we have, here letters are
>>>> filters:
>>>>
>>>> [outside filter] -> {A -> [state change decides to send to] -> B
>>>> -> [state change decides to send to] -> C} -> [outside filter]
>>>>
>>>> is very confusing. What protocol would require that? Just an honest
>>>> question; one does not come to my mind atm.
>>>>
>>> all of them :) This is what we currently do in MINA.
>>>
>> I think that I am hearing a reply that explains that all the protocols are
>> implemented in this way. I'm not hearing an explanation as to why it *must*
>> be that way.
>>
>
> simply because you can't move to the next filter unless you have
> transformed what you've got from the previous filter. If we exclude all the
> utility filters (like the loggers), a filter can only process a certain type
> of message, and produce another type of message. The chain of filters is
> dictated by the transformation done at each step. One good example is LDAP
> processing : in order to decode a LDAP message, you first have to decode the
> TLVs, then you can decode the messages themselves. A LDAP chain would be
> something like :
>
> [outside filter] -> (bytes) -> { TLV decoder filter -> (TLVs) -> LDAP
> decoder filter -> (LDAPmessages) } -> [outside filter]
>
> (add to this the fact that you may loop on the TLV filter *and* the LDAP
> filter, plus the fact that you may have to wait for more bytes)
>
> Now, it makes *no sense* to exchange the filters. It will simply not work.
> It's the very same for any protocol we will process with such a mechanism.
>
> In other words, the order the filters are executed is not random. It's
> fixed by design, and does not change (as soon as we have ruled out the
> possibility to have a dynamic chain).
>
>
> Another way to see this mechanism is that it's a path from one point to
> another : you may have many different paths, but for a set of bytes, you
> will always follow the same path. The only way to follow two different paths
> is when you get two different sets of bytes.
>
>
Emmanuel, thanks for chiming in here on behalf of the ASN.1 based codecs.
Alan these concepts are very important for us to factor in.
The problem here is that processing in one state of an FSM may alter the
control flow.
I know we're trying to find the design that leads to the sweetest and
easiest code for implementing these filters. However it's possible that this
process of defining protocols may evolve to where protocol implementors feed
in a state transition matrix and most of the code is generated minus
customizations supplied for actions to take.
I might be flying in the clouds with this but it might be another one of the
design constraints added to Emmanuel's list to at least consider.
--
Best Regards,
-- Alex
Re: [MINA 3.0] filter chains
Posted by Alex Karasulu <ak...@apache.org>.
On Fri, Aug 26, 2011 at 9:47 PM, Alan D. Cabrera <li...@toolazydogs.com>wrote:
>
> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>
> > On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
> >> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
> >> What I have in mind is much more something like :
> >>
> >> void messageReceived( context )
> >> {
> >> ... // do something, updating the context, eventually setting a
> status
> >> controller.callNextFilter( context, currentFilter );
> >> ... // do something after the call
> >> }
> >>
> >> and in controller :
> >> void callNextFilter( Context context, Filter currentFilter )
> >> {
> >> Status status = context.getStatus();
> >> Map<Status, Filter> map = fsmMap.get( currentFilter );
> >> Filter nextFilter = map.get( status );
> >>
> >> nextFilter.messageReceived( context );
> >> }
> >> This strikes me as pretty complex, jmho. Also, I don't like the idea of
> forcing the filter to call the controller.callNextFilter() to make things
> work.
> > the alternative would be something like :
> >
> > void messageReceived( context )
> > {
> > ... // do something, updating the context, eventually setting a status
> > fsmMap.get( this ).get( status ).messageReceived( context );
> > ... // do something after the call
> > }
> >
> > No controller, but a long list of chained call.
>
> But we're still forcing the filter to participate in things that really
> should be the domain of the controller not the filter.
>
> With that said I think that an FSM where we have, here letters are filters:
>
> [outside filter] -> {A -> [state change decides to send to] -> B -> [state
> change decides to send to] -> C} -> [outside filter]
>
> is very confusing. What protocol would require that? Just an honest
> question; one does not come to my mind atm.
>
> > Also the fsmMap must be known by the current filter.
> >> Look at my implementation of org.apache.mina.link.DownState as an
> example. This framework does not require a call to a controller for the
> whole thing to work. This filter merely focuses on its task at hand and
> implementation does not leak as much into its message received method.
> >
> > Ok, I'll give it a look.
> >>
> >>> The controller will decide which filter must be called depending on the
> context status.
> >>>
> >>> (Note that the controller should also decide which message to call, for
> instance, it can decide that it has to call a messageReceived() because it's
> caller was processing a messageReceived())
> >> I feel that, for the most part, we all have been doing a lot of
> discussions without any mock implementations of real protocols to help us
> gauge our API decisions.
> > I'm "lucky" enough to have played with MINA for more than 5 years, facing
> many differents kind of protocol based on it, plus having answered many of
> MINA user's questions regarding how to implement many different kind of
> protocol.
> >
> > Trust me on that, when I'm thinking about the new API, I always have in
> mind the different "real world" protocols we have to deal with. That
> includes :
> > - obviously LDAP protocol, which is a binary, two layer codec, demuxed
> protocol
> > - NTP based on UDP
> > - Kerberos based on UDP *and* TCP
> > - HTTP, ie newline terminated decoder, a cumulative decoder
> > - a few proprietary protocole implemented using MINA, with fixed size
> data, or LV type PDUs
>
> I think you missed my point. I am not questioning anyone's expertise in
> the industry. I am calling out the current modus operandi of the current
> API design process and it's need for real world mockups.
>
> >> Our tendency is to dive into the implementation details and then
> shoehorn protocols into the resultant API.
> > Not exactly my state of mind... I'm more trying to find the best possible
> solution, dealing with many constraints :
> > - ease of use
> > - coverage of the different use cases
> > - memory consumption
> > - ease of debuging
> > - speed
>
> Definitely good points. We all want this but they speak nothing to the
> process of coming up with an API. My point is to have concrete examples of
> how the API bits we are proposing would look. A perfect example is your and
> my ideas of how the FSM should work. With no concrete mocked up bits to see
> how the two APIs would influence the implementation of a protocol the
> discussion devolves into arguments over aesthetic opinions.
>
> >> This is why Mina 2 is so bloated and daunting.
> > MINA 2 is bloated for different reasons, and I think I have already
> discussed some of them.
> >
> > One of the most problematic reason is that MINA 2 (and 1) was a one man
> show. This is why I'm really pleased to have those discussion here, even if
> it seems to be a bike-shedding discussion. It is not.
>
+1
I'm glad to see these discussions. They're getting more and more concrete
every day.
>
> Agreed on the last bit. Anyone who thinks the current discussions about
> the API design are bike shed issues never designed an API.
>
> >> I'd like to see lots of little sandbox branches where people show what
> protocol implementations would end up looking like for the feature they are
> proposing. It's a fantastic way to gauge API design differences.
> > I like Julien's approach : designing a working solution, not covering all
> our bases right now, and implement a few existing protocols. Then moving
> forward.
>
> I'm sorry but that seems totally backwards to me. The API design should be
> the framework from which the working solution evolves. Starting with the
> implementations could automatically close the doors on useful API features.
>
>
+1
This methodology is a faster version of how MINA 2 evolved: out of need. It
might bind us to constructs that are not that easy to evolve out of as was
the case for MINA 2.
I agree with Alan about mock ups for various protocols because it will show
clearly which approach is cleaner. We can even benchmark performance and
also see if the debugging process is a PITA. It's the comprehensive way to
go. Let's face it the code base is small but getting the API right is hard.
Experimenting with multiple incarnations and implementations will show us
the best path.
--
Best Regards,
-- Alex
Re: [MINA 3.0] filter chains
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Aug 26, 2011, at 7:54 AM, Emmanuel Lecharny wrote:
> On 8/26/11 4:41 PM, Julien Vermillard wrote:
>> On Fri, Aug 26, 2011 at 4:28 PM, Alan D. Cabrera<li...@toolazydogs.com> wrote:
>>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>>
>>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny<el...@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<li...@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 think we need to avoid complex feature like graph. IMHO server in
>> MINA is a codec and an handler 90% of the time. Someone have a use
>> case which could use filter graph with MINA ?
>
> yes. We use it for LDAP... And we have had some users asking how to manage a decoder for multiple kind of messages.
>
> This is not something we want just because it's beautiful.
>
> Now, what about having a controller hidding the internal structure, so that we can switch to a graph later ? IMO, we should not expose the inner data structure, be it a list or a graph. It's the controller's business to deal with that.
>
> However, we must provide the current state to the controller, it's not enough to provide the current filter.
Look at how things are set up in my sandbox. The parents and children can have any cardinality, even zero. The controller should be able to automatically handle all of that.
Regards,
Alan
Re: [MINA 3.0] filter chains
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 8/26/11 4:41 PM, Julien Vermillard wrote:
> On Fri, Aug 26, 2011 at 4:28 PM, Alan D. Cabrera<li...@toolazydogs.com> wrote:
>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>
>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny<el...@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<li...@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 think we need to avoid complex feature like graph. IMHO server in
> MINA is a codec and an handler 90% of the time. Someone have a use
> case which could use filter graph with MINA ?
yes. We use it for LDAP... And we have had some users asking how to
manage a decoder for multiple kind of messages.
This is not something we want just because it's beautiful.
Now, what about having a controller hidding the internal structure, so
that we can switch to a graph later ? IMO, we should not expose the
inner data structure, be it a list or a graph. It's the controller's
business to deal with that.
However, we must provide the current state to the controller, it's not
enough to provide the current filter.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re : Re : [MINA 3.0] filter chains
Posted by Edouard De Oliveira <do...@yahoo.fr>.
De : Emmanuel Lécharny <el...@apache.org>
À : dev@mina.apache.org
Cc :
Envoyé le : Vendredi 26 Août 2011 18h10
Objet : Re: Re : [MINA 3.0] filter chains
On 8/26/11 6:02 PM, Edouard De Oliveira wrote:
> De : Emmanuel Lecharny<el...@gmail.com>
>
>
> The theory sounds ok but it also seems that Alan has something much more (too ?) complex in mind for those who wandered what a DAG is i think it's this http://en.wikipedia.org/wiki/Directed_acyclic_graph do you confirm alan ?
>DAG is just a restricted form of a FSM. It just forbid a loop, which is exactly what we need in our case (why would we cycle on a filter we >already went through ?)
The concept is a basic it's just the acronym that may not be known ...
-- Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Re : [MINA 3.0] filter chains
Posted by Emmanuel Lécharny <el...@apache.org>.
On 8/26/11 6:02 PM, Edouard De Oliveira wrote:
> De : Emmanuel Lecharny<el...@gmail.com>
>
>
> The theory sounds ok but it also seems that Alan has something much more (too ?) complex in mind
> for those who wandered what a DAG is i think it's this http://en.wikipedia.org/wiki/Directed_acyclic_graph do you confirm alan ?
DAG is just a restricted form of a FSM. It just forbid a loop, which is
exactly what we need in our case (why would we cycle on a filter we
already went through ?)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Aug 26, 2011, at 9:02 AM, Edouard De Oliveira wrote:
> De : Emmanuel Lecharny <el...@gmail.com>
>
> À : dev@mina.apache.org
> Envoyé le : Vendredi 26 Août 2011 17h12
> Objet : Re: [MINA 3.0] filter chains
>
> 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<el...@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<li...@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>
>
>
> The theory sounds ok but it also seems that Alan has something much more (too ?) complex in mind
> for those who wandered what a DAG is i think it's this http://en.wikipedia.org/wiki/Directed_acyclic_graph do you confirm alan ?
Yes, this is the definition of a DAG but I am using it to precisely state the characteristics of the graph. Simply put, no circularities.
A tree is a DAG. MUX/DEMUX is a DAG.
As I mentioned, it's a simple straightforward concept that every programmer should know. The benefit is that it dramatically keeps things simpler by removing circularities.
Regards,
Alan
Re : [MINA 3.0] filter chains
Posted by Edouard De Oliveira <do...@yahoo.fr>.
De : Emmanuel Lecharny <el...@gmail.com>
À : dev@mina.apache.org
Envoyé le : Vendredi 26 Août 2011 17h12
Objet : Re: [MINA 3.0] filter chains
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<el...@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<li...@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>
The theory sounds ok but it also seems that Alan has something much more (too ?) complex in mind
for those who wandered what a DAG is i think it's this http://en.wikipedia.org/wiki/Directed_acyclic_graph do you confirm alan ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 8/28/11 8:09 PM, Alan D. Cabrera wrote:
> On Aug 28, 2011, at 10:44 AM, Emmanuel Lecharny wrote:
>
>> On 8/28/11 6:27 PM, Alan D. Cabrera wrote:
>>> On Aug 27, 2011, at 1:51 PM, Alan D. Cabrera wrote:
>>>
>>> I took a bit of time to start fleshing out an LDAP server and now know why we've been back and forth so often. You are using an FSM to parse messages and I am using FSMs to implement network protocols.
>> We are using a FSM to decode the LDAP messages, but this is an orthogonal concern here.
> Are you restating what I have just said? I fear I may be missing some point.
I just say that the fact the LDAP decoder is using a FSM is irrelevant
to the MINA chain"s discussion.
>
>> The problem we had with MINA is that we would have prefered to have two decoder filters : one for the TLVs and another one for the LDAP messages. It was not possible when we first created this decoder.
> In ASN.1 this may not be possible given the different encoding rules. Some of which force the "merging" of TLV and message parsing, i.e. some rules allow for the eliding of tags. Not sure if that is relevant to LDAP which may force the use of BER.
Of course, TLVs are only important when decoding BER/CER encoded ASN/1.
You can't decode PER encoded ASN.1 using this technic. LDAP mandates
that BER is used.
>
>> Also we have to use a demux at the end, and it's a PITA. Would we be able to use a FSM to implment the LDAP protocol as a whole, we would be more than happy.
> This is an interesting statement. Can you provide more detail?
Sure : the LDAP decoder is actually managed in one single filter. The
problem is that we have to decode the TLVs first, before being able to
determinate which kind of message we are dealing with. For instance, a
Search request always starts with the following bytes (where NN is an
encoded integer, and LL is the Value length ):
0x30 LL 0x02 0x0[1..4] NN 0x63 LL ...
A Bind request starts with the following bytes :
0x30 LL 0x02 0x0[1..4] NN 0x60 LL ...
As you can see, until we have decoded the third TLV, we have no idea
what kind of LDAP message we are dealing with.
Now, once the message has been decoded, we transmit it to the next
Filter which calls the right handler, depending on the message. That
means the Handler extends DemuxingIoHandler, which requires that you
configure a Map associating a message type with a dedicated handler.
If we were using a FSM instead, then the message would just have to call
the right filter, the one which redirect to the associated handler
>
>>> Two totally different things. I think we should think about this for a bit but I will quickly state that I think the way to handle this is to have something not unlike an SSL engine inside a filter;
>> SSL as a filter was a big mistake, IMHO.
> It may have no industry use but I think can serve as a nice POC for using a parsing engine inside an FSM, a pattern that I think may be applicable to LDAP messages.
The very problem of the SSL filter is that it *must* be placed in the
first position in the chain, because it initiates a dialog with the
client in order to establish the encrypted session.
At some point, it can probably be managed by a FSM, too.
Regarding using a generic FSM to decode LDAP messages, well, that's a
very interesting idea. We even discussed a while back about using the
MINA's stateMachine project, but w never went any further, due to lack
of time.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Aug 28, 2011, at 10:44 AM, Emmanuel Lecharny wrote:
> On 8/28/11 6:27 PM, Alan D. Cabrera wrote:
>> On Aug 27, 2011, at 1:51 PM, Alan D. Cabrera wrote:
>>
>> I took a bit of time to start fleshing out an LDAP server and now know why we've been back and forth so often. You are using an FSM to parse messages and I am using FSMs to implement network protocols.
> We are using a FSM to decode the LDAP messages, but this is an orthogonal concern here.
Are you restating what I have just said? I fear I may be missing some point.
> The problem we had with MINA is that we would have prefered to have two decoder filters : one for the TLVs and another one for the LDAP messages. It was not possible when we first created this decoder.
In ASN.1 this may not be possible given the different encoding rules. Some of which force the "merging" of TLV and message parsing, i.e. some rules allow for the eliding of tags. Not sure if that is relevant to LDAP which may force the use of BER.
> Also we have to use a demux at the end, and it's a PITA. Would we be able to use a FSM to implment the LDAP protocol as a whole, we would be more than happy.
This is an interesting statement. Can you provide more detail?
>> Two totally different things. I think we should think about this for a bit but I will quickly state that I think the way to handle this is to have something not unlike an SSL engine inside a filter;
> SSL as a filter was a big mistake, IMHO.
It may have no industry use but I think can serve as a nice POC for using a parsing engine inside an FSM, a pattern that I think may be applicable to LDAP messages.
Regards,
Alan
Re: [MINA 3.0] filter chains
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 8/28/11 6:27 PM, Alan D. Cabrera wrote:
> On Aug 27, 2011, at 1:51 PM, Alan D. Cabrera wrote:
>
> I took a bit of time to start fleshing out an LDAP server and now know why we've been back and forth so often. You are using an FSM to parse messages and I am using FSMs to implement network protocols.
We are using a FSM to decode the LDAP messages, but this is an
orthogonal concern here.
The problem we had with MINA is that we would have prefered to have two
decoder filters : one for the TLVs and another one for the LDAP
messages. It was not possible when we first created this decoder. Also
we have to use a demux at the end, and it's a PITA. Would we be able to
use a FSM to implment the LDAP protocol as a whole, we would be more
than happy.
> Two totally different things. I think we should think about this for a bit but I will quickly state that I think the way to handle this is to have something not unlike an SSL engine inside a filter;
SSL as a filter was a big mistake, IMHO.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
On Aug 27, 2011, at 1:51 PM, Alan D. Cabrera wrote:
>
> On Aug 26, 2011, at 7:35 PM, Emmanuel Lecharny wrote:
>
>> On 8/27/11 2:04 AM, Alan D. Cabrera wrote:
>>
>> simply because you can't move to the next filter unless you have transformed what you've got from the previous filter. If we exclude all the utility filters (like the loggers), a filter can only process a certain type of message, and produce another type of message. The chain of filters is dictated by the transformation done at each step. One good example is LDAP processing : in order to decode a LDAP message, you first have to decode the TLVs, then you can decode the messages themselves. A LDAP chain would be something like :
>>
>> [outside filter] -> (bytes) -> { TLV decoder filter -> (TLVs) -> LDAP decoder filter -> (LDAPmessages) } -> [outside filter]
>>
>> (add to this the fact that you may loop on the TLV filter *and* the LDAP filter, plus the fact that you may have to wait for more bytes)
>>
>> Now, it makes *no sense* to exchange the filters. It will simply not work. It's the very same for any protocol we will process with such a mechanism.
>>
>> In other words, the order the filters are executed is not random. It's fixed by design, and does not change (as soon as we have ruled out the possibility to have a dynamic chain).
>>
>>
>> Another way to see this mechanism is that it's a path from one point to another : you may have many different paths, but for a set of bytes, you will always follow the same path. The only way to follow two different paths is when you get two different sets of bytes.
>
> I'm not sure that this needs to be a single FSM. Why not
>
> [outside filter] -> (bytes) -> [TLV decoder filter] -> (TLVs) -> [LDAP decoder filter] -> (LDAPmessages) -> [outside filter]
>
> I hear "looping" being a justification but it strikes me that using an FSM obfuscates things needlessly as I believe that a simple filter will do.
>
> Is there some code I can look at to see your above implementation? I think here is a perfect case for code bits to compare.
I took a bit of time to start fleshing out an LDAP server and now know why we've been back and forth so often. You are using an FSM to parse messages and I am using FSMs to implement network protocols. Two totally different things. I think we should think about this for a bit but I will quickly state that I think the way to handle this is to have something not unlike an SSL engine inside a filter; look at my sloppy sketch that's "evolving" in my sandbox.
Regards,
Alan
Re: [MINA 3.0] filter chains
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Aug 26, 2011, at 7:35 PM, Emmanuel Lecharny wrote:
> On 8/27/11 2:04 AM, Alan D. Cabrera wrote:
>> On Aug 26, 2011, at 1:27 PM, Emmanuel Lecharny wrote:
>>
>>> On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
>>>> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>>>>
>>>>> On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
>>>>>> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
>>>>>> What I have in mind is much more something like :
>>>>>>
>>>>>> void messageReceived( context )
>>>>>> {
>>>>>> ... // do something, updating the context, eventually setting a status
>>>>>> controller.callNextFilter( context, currentFilter );
>>>>>> ... // do something after the call
>>>>>> }
>>>>>>
>>>>>> and in controller :
>>>>>> void callNextFilter( Context context, Filter currentFilter )
>>>>>> {
>>>>>> Status status = context.getStatus();
>>>>>> Map<Status, Filter> map = fsmMap.get( currentFilter );
>>>>>> Filter nextFilter = map.get( status );
>>>>>>
>>>>>> nextFilter.messageReceived( context );
>>>>>> }
>>>>>> This strikes me as pretty complex, jmho. Also, I don't like the idea of forcing the filter to call the controller.callNextFilter() to make things work.
>>>>> the alternative would be something like :
>>>>>
>>>>> void messageReceived( context )
>>>>> {
>>>>> ... // do something, updating the context, eventually setting a status
>>>>> fsmMap.get( this ).get( status ).messageReceived( context );
>>>>> ... // do something after the call
>>>>> }
>>>>>
>>>>> No controller, but a long list of chained call.
>>>> But we're still forcing the filter to participate in things that really should be the domain of the controller not the filter.
>>> If we delegate the transition to the controller, then we can't have post actions... Obviously, not having post actions makes it easier. (Post action are really important if we want to do something when we come back from the application.)
>> I think we're getting to some interesting bits. Can you provide more exact detail?
>
> One very simple example, taken from the ProfilerFilter :
>
> @Override
> public void messageReceived(NextFilter nextFilter, IoSession session,
> Object message) throws Exception {
> if (profileMessageReceived) {
> long start = timeNow();
> nextFilter.messageReceived(session, message);
> long end = timeNow();
> messageReceivedTimerWorker.addNewDuration(end - start);
> } else {
> nextFilter.messageReceived(session, message);
> }
> }
>
> If you depend on the controller to call thenext filter, then you have no easy way to compute the time it takes to process the action, as you won't be able to execute the post action.
This is a good use case, instrumentation of the protocol stack. Something to think about.
What I still object to is forcing filters to participate via this code bit:
fsmMap.get( this ).get( status ).messageReceived( context );
>
> Note that the decoding of multiple messages within one PDU won't be possible either without being able to process post-actions. (see below)
>>> One clear exemple would be a decoder processing a PDU with more than one message : you can't anymore loop on the PDU if you delegate the next call to the controller.
>> What is the format of this PDU and how is it presented to the FSM, i.e. in what kind of pieces does it arrive?
>
> You get an array of bytes, containing potentially more than one message. The fact is that you have no way to get a byte array from the socket as soon as a complete message has been received : the socket does not know anything about messages.
>
> You just have to assume that the PDU you've got can be :
> - either a portion of a message, and you have to wait for more bytes in order to produce a message
> - a full message, once decoded
> - more than one message you have to send to the handler one by one
> - some full messages plus a fraction of a message
I had/have the same understanding of how to crack a PDU and pass on translated messages. This can easily, and I think a fare bit cleaner, be accomplished using the mechanism that I propose as well.
>>>> With that said I think that an FSM where we have, here letters are filters:
>>>>
>>>> [outside filter] -> {A -> [state change decides to send to] -> B -> [state change decides to send to] -> C} -> [outside filter]
>>>>
>>>> is very confusing. What protocol would require that? Just an honest question; one does not come to my mind atm.
>>> all of them :) This is what we currently do in MINA.
>> I think that I am hearing a reply that explains that all the protocols are implemented in this way. I'm not hearing an explanation as to why it *must* be that way.
>
> simply because you can't move to the next filter unless you have transformed what you've got from the previous filter. If we exclude all the utility filters (like the loggers), a filter can only process a certain type of message, and produce another type of message. The chain of filters is dictated by the transformation done at each step. One good example is LDAP processing : in order to decode a LDAP message, you first have to decode the TLVs, then you can decode the messages themselves. A LDAP chain would be something like :
>
> [outside filter] -> (bytes) -> { TLV decoder filter -> (TLVs) -> LDAP decoder filter -> (LDAPmessages) } -> [outside filter]
>
> (add to this the fact that you may loop on the TLV filter *and* the LDAP filter, plus the fact that you may have to wait for more bytes)
>
> Now, it makes *no sense* to exchange the filters. It will simply not work. It's the very same for any protocol we will process with such a mechanism.
>
> In other words, the order the filters are executed is not random. It's fixed by design, and does not change (as soon as we have ruled out the possibility to have a dynamic chain).
>
>
> Another way to see this mechanism is that it's a path from one point to another : you may have many different paths, but for a set of bytes, you will always follow the same path. The only way to follow two different paths is when you get two different sets of bytes.
I'm not sure that this needs to be a single FSM. Why not
[outside filter] -> (bytes) -> [TLV decoder filter] -> (TLVs) -> [LDAP decoder filter] -> (LDAPmessages) -> [outside filter]
I hear "looping" being a justification but it strikes me that using an FSM obfuscates things needlessly as I believe that a simple filter will do.
Is there some code I can look at to see your above implementation? I think here is a perfect case for code bits to compare.
Regards,
Alan
Re: [MINA 3.0] filter chains
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 8/27/11 2:04 AM, Alan D. Cabrera wrote:
> On Aug 26, 2011, at 1:27 PM, Emmanuel Lecharny wrote:
>
>> On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
>>> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>>>
>>>> On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
>>>>> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
>>>>> What I have in mind is much more something like :
>>>>>
>>>>> void messageReceived( context )
>>>>> {
>>>>> ... // do something, updating the context, eventually setting a status
>>>>> controller.callNextFilter( context, currentFilter );
>>>>> ... // do something after the call
>>>>> }
>>>>>
>>>>> and in controller :
>>>>> void callNextFilter( Context context, Filter currentFilter )
>>>>> {
>>>>> Status status = context.getStatus();
>>>>> Map<Status, Filter> map = fsmMap.get( currentFilter );
>>>>> Filter nextFilter = map.get( status );
>>>>>
>>>>> nextFilter.messageReceived( context );
>>>>> }
>>>>> This strikes me as pretty complex, jmho. Also, I don't like the idea of forcing the filter to call the controller.callNextFilter() to make things work.
>>>> the alternative would be something like :
>>>>
>>>> void messageReceived( context )
>>>> {
>>>> ... // do something, updating the context, eventually setting a status
>>>> fsmMap.get( this ).get( status ).messageReceived( context );
>>>> ... // do something after the call
>>>> }
>>>>
>>>> No controller, but a long list of chained call.
>>> But we're still forcing the filter to participate in things that really should be the domain of the controller not the filter.
>> If we delegate the transition to the controller, then we can't have post actions... Obviously, not having post actions makes it easier. (Post action are really important if we want to do something when we come back from the application.)
> I think we're getting to some interesting bits. Can you provide more exact detail?
One very simple example, taken from the ProfilerFilter :
@Override
public void messageReceived(NextFilter nextFilter, IoSession session,
Object message) throws Exception {
if (profileMessageReceived) {
long start = timeNow();
nextFilter.messageReceived(session, message);
long end = timeNow();
messageReceivedTimerWorker.addNewDuration(end - start);
} else {
nextFilter.messageReceived(session, message);
}
}
If you depend on the controller to call thenext filter, then you have no
easy way to compute the time it takes to process the action, as you
won't be able to execute the post action.
Note that the decoding of multiple messages within one PDU won't be
possible either without being able to process post-actions. (see below)
>> One clear exemple would be a decoder processing a PDU with more than one message : you can't anymore loop on the PDU if you delegate the next call to the controller.
> What is the format of this PDU and how is it presented to the FSM, i.e. in what kind of pieces does it arrive?
You get an array of bytes, containing potentially more than one message.
The fact is that you have no way to get a byte array from the socket as
soon as a complete message has been received : the socket does not know
anything about messages.
You just have to assume that the PDU you've got can be :
- either a portion of a message, and you have to wait for more bytes in
order to produce a message
- a full message, once decoded
- more than one message you have to send to the handler one by one
- some full messages plus a fraction of a message
>
>>> With that said I think that an FSM where we have, here letters are filters:
>>>
>>> [outside filter] -> {A -> [state change decides to send to] -> B -> [state change decides to send to] -> C} -> [outside filter]
>>>
>>> is very confusing. What protocol would require that? Just an honest question; one does not come to my mind atm.
>> all of them :) This is what we currently do in MINA.
> I think that I am hearing a reply that explains that all the protocols are implemented in this way. I'm not hearing an explanation as to why it *must* be that way.
simply because you can't move to the next filter unless you have
transformed what you've got from the previous filter. If we exclude all
the utility filters (like the loggers), a filter can only process a
certain type of message, and produce another type of message. The chain
of filters is dictated by the transformation done at each step. One good
example is LDAP processing : in order to decode a LDAP message, you
first have to decode the TLVs, then you can decode the messages
themselves. A LDAP chain would be something like :
[outside filter] -> (bytes) -> { TLV decoder filter -> (TLVs) -> LDAP
decoder filter -> (LDAPmessages) } -> [outside filter]
(add to this the fact that you may loop on the TLV filter *and* the LDAP
filter, plus the fact that you may have to wait for more bytes)
Now, it makes *no sense* to exchange the filters. It will simply not
work. It's the very same for any protocol we will process with such a
mechanism.
In other words, the order the filters are executed is not random. It's
fixed by design, and does not change (as soon as we have ruled out the
possibility to have a dynamic chain).
Another way to see this mechanism is that it's a path from one point to
another : you may have many different paths, but for a set of bytes, you
will always follow the same path. The only way to follow two different
paths is when you get two different sets of bytes.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Aug 26, 2011, at 1:27 PM, Emmanuel Lecharny wrote:
> On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
>> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>>
>>> On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
>>>> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
>>>> What I have in mind is much more something like :
>>>>
>>>> void messageReceived( context )
>>>> {
>>>> ... // do something, updating the context, eventually setting a status
>>>> controller.callNextFilter( context, currentFilter );
>>>> ... // do something after the call
>>>> }
>>>>
>>>> and in controller :
>>>> void callNextFilter( Context context, Filter currentFilter )
>>>> {
>>>> Status status = context.getStatus();
>>>> Map<Status, Filter> map = fsmMap.get( currentFilter );
>>>> Filter nextFilter = map.get( status );
>>>>
>>>> nextFilter.messageReceived( context );
>>>> }
>>>> This strikes me as pretty complex, jmho. Also, I don't like the idea of forcing the filter to call the controller.callNextFilter() to make things work.
>>> the alternative would be something like :
>>>
>>> void messageReceived( context )
>>> {
>>> ... // do something, updating the context, eventually setting a status
>>> fsmMap.get( this ).get( status ).messageReceived( context );
>>> ... // do something after the call
>>> }
>>>
>>> No controller, but a long list of chained call.
>> But we're still forcing the filter to participate in things that really should be the domain of the controller not the filter.
>
> If we delegate the transition to the controller, then we can't have post actions... Obviously, not having post actions makes it easier. (Post action are really important if we want to do something when we come back from the application.)
I think we're getting to some interesting bits. Can you provide more exact detail?
>
> One clear exemple would be a decoder processing a PDU with more than one message : you can't anymore loop on the PDU if you delegate the next call to the controller.
What is the format of this PDU and how is it presented to the FSM, i.e. in what kind of pieces does it arrive?
>> With that said I think that an FSM where we have, here letters are filters:
>>
>> [outside filter] -> {A -> [state change decides to send to] -> B -> [state change decides to send to] -> C} -> [outside filter]
>>
>> is very confusing. What protocol would require that? Just an honest question; one does not come to my mind atm.
>
> all of them :) This is what we currently do in MINA.
I think that I am hearing a reply that explains that all the protocols are implemented in this way. I'm not hearing an explanation as to why it *must* be that way.
Regards,
Alan
Re: [MINA 3.0] filter chains
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>
>> On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
>>> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
>>> What I have in mind is much more something like :
>>>
>>> void messageReceived( context )
>>> {
>>> ... // do something, updating the context, eventually setting a status
>>> controller.callNextFilter( context, currentFilter );
>>> ... // do something after the call
>>> }
>>>
>>> and in controller :
>>> void callNextFilter( Context context, Filter currentFilter )
>>> {
>>> Status status = context.getStatus();
>>> Map<Status, Filter> map = fsmMap.get( currentFilter );
>>> Filter nextFilter = map.get( status );
>>>
>>> nextFilter.messageReceived( context );
>>> }
>>> This strikes me as pretty complex, jmho. Also, I don't like the idea of forcing the filter to call the controller.callNextFilter() to make things work.
>> the alternative would be something like :
>>
>> void messageReceived( context )
>> {
>> ... // do something, updating the context, eventually setting a status
>> fsmMap.get( this ).get( status ).messageReceived( context );
>> ... // do something after the call
>> }
>>
>> No controller, but a long list of chained call.
> But we're still forcing the filter to participate in things that really should be the domain of the controller not the filter.
If we delegate the transition to the controller, then we can't have post
actions... Obviously, not having post actions makes it easier. (Post
action are really important if we want to do something when we come back
from the application.)
One clear exemple would be a decoder processing a PDU with more than one
message : you can't anymore loop on the PDU if you delegate the next
call to the controller.
>
>
> With that said I think that an FSM where we have, here letters are filters:
>
> [outside filter] -> {A -> [state change decides to send to] -> B -> [state change decides to send to] -> C} -> [outside filter]
>
> is very confusing. What protocol would require that? Just an honest question; one does not come to my mind atm.
all of them :) This is what we currently do in MINA.
>
>> Also the fsmMap must be known by the current filter.
>>> Look at my implementation of org.apache.mina.link.DownState as an example. This framework does not require a call to a controller for the whole thing to work. This filter merely focuses on its task at hand and implementation does not leak as much into its message received method.
>> Ok, I'll give it a look.
>>>> The controller will decide which filter must be called depending on the context status.
>>>>
>>>> (Note that the controller should also decide which message to call, for instance, it can decide that it has to call a messageReceived() because it's caller was processing a messageReceived())
>>> I feel that, for the most part, we all have been doing a lot of discussions without any mock implementations of real protocols to help us gauge our API decisions.
>> I'm "lucky" enough to have played with MINA for more than 5 years, facing many differents kind of protocol based on it, plus having answered many of MINA user's questions regarding how to implement many different kind of protocol.
>>
>> Trust me on that, when I'm thinking about the new API, I always have in mind the different "real world" protocols we have to deal with. That includes :
>> - obviously LDAP protocol, which is a binary, two layer codec, demuxed protocol
>> - NTP based on UDP
>> - Kerberos based on UDP *and* TCP
>> - HTTP, ie newline terminated decoder, a cumulative decoder
>> - a few proprietary protocole implemented using MINA, with fixed size data, or LV type PDUs
> I think you missed my point. I am not questioning anyone's expertise in the industry. I am calling out the current modus operandi of the current API design process and it's need for real world mockups.
Ok, understood. You are reverting the process : we define the protocols,
then we try to implement them with different way to manage filters.
>
>>> I'd like to see lots of little sandbox branches where people show what protocol implementations would end up looking like for the feature they are proposing. It's a fantastic way to gauge API design differences.
>> I like Julien's approach : designing a working solution, not covering all our bases right now, and implement a few existing protocols. Then moving forward.
> I'm sorry but that seems totally backwards to me. The API design should be the framework from which the working solution evolves. Starting with the implementations could automatically close the doors on useful API features.
Unless we ditch those implementations. But I understand your point.
However, even if we define some protocols, we will need some
implementation to test them.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
> On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
>> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
>> What I have in mind is much more something like :
>>
>> void messageReceived( context )
>> {
>> ... // do something, updating the context, eventually setting a status
>> controller.callNextFilter( context, currentFilter );
>> ... // do something after the call
>> }
>>
>> and in controller :
>> void callNextFilter( Context context, Filter currentFilter )
>> {
>> Status status = context.getStatus();
>> Map<Status, Filter> map = fsmMap.get( currentFilter );
>> Filter nextFilter = map.get( status );
>>
>> nextFilter.messageReceived( context );
>> }
>> This strikes me as pretty complex, jmho. Also, I don't like the idea of forcing the filter to call the controller.callNextFilter() to make things work.
> the alternative would be something like :
>
> void messageReceived( context )
> {
> ... // do something, updating the context, eventually setting a status
> fsmMap.get( this ).get( status ).messageReceived( context );
> ... // do something after the call
> }
>
> No controller, but a long list of chained call.
But we're still forcing the filter to participate in things that really should be the domain of the controller not the filter.
With that said I think that an FSM where we have, here letters are filters:
[outside filter] -> {A -> [state change decides to send to] -> B -> [state change decides to send to] -> C} -> [outside filter]
is very confusing. What protocol would require that? Just an honest question; one does not come to my mind atm.
> Also the fsmMap must be known by the current filter.
>> Look at my implementation of org.apache.mina.link.DownState as an example. This framework does not require a call to a controller for the whole thing to work. This filter merely focuses on its task at hand and implementation does not leak as much into its message received method.
>
> Ok, I'll give it a look.
>>
>>> The controller will decide which filter must be called depending on the context status.
>>>
>>> (Note that the controller should also decide which message to call, for instance, it can decide that it has to call a messageReceived() because it's caller was processing a messageReceived())
>> I feel that, for the most part, we all have been doing a lot of discussions without any mock implementations of real protocols to help us gauge our API decisions.
> I'm "lucky" enough to have played with MINA for more than 5 years, facing many differents kind of protocol based on it, plus having answered many of MINA user's questions regarding how to implement many different kind of protocol.
>
> Trust me on that, when I'm thinking about the new API, I always have in mind the different "real world" protocols we have to deal with. That includes :
> - obviously LDAP protocol, which is a binary, two layer codec, demuxed protocol
> - NTP based on UDP
> - Kerberos based on UDP *and* TCP
> - HTTP, ie newline terminated decoder, a cumulative decoder
> - a few proprietary protocole implemented using MINA, with fixed size data, or LV type PDUs
I think you missed my point. I am not questioning anyone's expertise in the industry. I am calling out the current modus operandi of the current API design process and it's need for real world mockups.
>> Our tendency is to dive into the implementation details and then shoehorn protocols into the resultant API.
> Not exactly my state of mind... I'm more trying to find the best possible solution, dealing with many constraints :
> - ease of use
> - coverage of the different use cases
> - memory consumption
> - ease of debuging
> - speed
Definitely good points. We all want this but they speak nothing to the process of coming up with an API. My point is to have concrete examples of how the API bits we are proposing would look. A perfect example is your and my ideas of how the FSM should work. With no concrete mocked up bits to see how the two APIs would influence the implementation of a protocol the discussion devolves into arguments over aesthetic opinions.
>> This is why Mina 2 is so bloated and daunting.
> MINA 2 is bloated for different reasons, and I think I have already discussed some of them.
>
> One of the most problematic reason is that MINA 2 (and 1) was a one man show. This is why I'm really pleased to have those discussion here, even if it seems to be a bike-shedding discussion. It is not.
Agreed on the last bit. Anyone who thinks the current discussions about the API design are bike shed issues never designed an API.
>> I'd like to see lots of little sandbox branches where people show what protocol implementations would end up looking like for the feature they are proposing. It's a fantastic way to gauge API design differences.
> I like Julien's approach : designing a working solution, not covering all our bases right now, and implement a few existing protocols. Then moving forward.
I'm sorry but that seems totally backwards to me. The API design should be the framework from which the working solution evolves. Starting with the implementations could automatically close the doors on useful API features.
Regards,
Alan
Re: [MINA 3.0] filter chains
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
> What I have in mind is much more something like :
>
> void messageReceived( context )
> {
> ... // do something, updating the context, eventually setting a status
> controller.callNextFilter( context, currentFilter );
> ... // do something after the call
> }
>
> and in controller :
> void callNextFilter( Context context, Filter currentFilter )
> {
> Status status = context.getStatus();
> Map<Status, Filter> map = fsmMap.get( currentFilter );
> Filter nextFilter = map.get( status );
>
> nextFilter.messageReceived( context );
> }
> This strikes me as pretty complex, jmho. Also, I don't like the idea of forcing the filter to call the controller.callNextFilter() to make things work.
the alternative would be something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
fsmMap.get( this ).get( status ).messageReceived( context );
... // do something after the call
}
No controller, but a long list of chained call.
Also the fsmMap must be known by the current filter.
> Look at my implementation of org.apache.mina.link.DownState as an example. This framework does not require a call to a controller for the whole thing to work. This filter merely focuses on its task at hand and implementation does not leak as much into its message received method.
Ok, I'll give it a look.
>
>> The controller will decide which filter must be called depending on the context status.
>>
>> (Note that the controller should also decide which message to call, for instance, it can decide that it has to call a messageReceived() because it's caller was processing a messageReceived())
> I feel that, for the most part, we all have been doing a lot of discussions without any mock implementations of real protocols to help us gauge our API decisions.
I'm "lucky" enough to have played with MINA for more than 5 years,
facing many differents kind of protocol based on it, plus having
answered many of MINA user's questions regarding how to implement many
different kind of protocol.
Trust me on that, when I'm thinking about the new API, I always have in
mind the different "real world" protocols we have to deal with. That
includes :
- obviously LDAP protocol, which is a binary, two layer codec, demuxed
protocol
- NTP based on UDP
- Kerberos based on UDP *and* TCP
- HTTP, ie newline terminated decoder, a cumulative decoder
- a few proprietary protocole implemented using MINA, with fixed size
data, or LV type PDUs
> Our tendency is to dive into the implementation details and then shoehorn protocols into the resultant API.
Not exactly my state of mind... I'm more trying to find the best
possible solution, dealing with many constraints :
- ease of use
- coverage of the different use cases
- memory consumption
- ease of debuging
- speed
> This is why Mina 2 is so bloated and daunting.
MINA 2 is bloated for different reasons, and I think I have already
discussed some of them.
One of the most problematic reason is that MINA 2 (and 1) was a one man
show. This is why I'm really pleased to have those discussion here, even
if it seems to be a bike-shedding discussion. It is not.
> I'd like to see lots of little sandbox branches where people show what protocol implementations would end up looking like for the feature they are proposing. It's a fantastic way to gauge API design differences.
I like Julien's approach : designing a working solution, not covering
all our bases right now, and implement a few existing protocols. Then
moving forward.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
> On 8/26/11 6:16 PM, Alan D. Cabrera wrote:
>> On Aug 26, 2011, at 9:10 AM, Emmanuel Lecharny wrote:
>>
>>> On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
>>>> On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
>>>>
>>>>
>>>> <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.
>> Ok, now I know where you're coming from. For me I have a map of chains
>>
>> Map<State, Chain> states = …
>> State current;
>
> What is Chain in this context ?
Chain is a simple filter or graph of filters that can declare what the next state of the FSM should be.
> I don't think it's enough to build the demux. We probably would need something like :
>
> Map<Status, Filter> filterMap = ...
> Map<Filter, Map<Status, Filter>> fsmMap = ...
>
> ( I keep Filter, but a Filter for us is a State in a FSM)
>
> otherwise, the controller can't select the next Filter without having a clue about the context
Ahh, cool, more clarity. I never intended FSMs to replace a demux.
>> void send(T message)
>> {
>> Chain chain = states.get(current);
>> current = chain.send(message);
>> }
>
> What I have in mind is much more something like :
>
> void messageReceived( context )
> {
> ... // do something, updating the context, eventually setting a status
> controller.callNextFilter( context, currentFilter );
> ... // do something after the call
> }
>
> and in controller :
> void callNextFilter( Context context, Filter currentFilter )
> {
> Status status = context.getStatus();
> Map<Status, Filter> map = fsmMap.get( currentFilter );
> Filter nextFilter = map.get( status );
>
> nextFilter.messageReceived( context );
> }
This strikes me as pretty complex, jmho. Also, I don't like the idea of forcing the filter to call the controller.callNextFilter() to make things work. Look at my implementation of org.apache.mina.link.DownState as an example. This framework does not require a call to a controller for the whole thing to work. This filter merely focuses on its task at hand and implementation does not leak as much into its message received method.
> The controller will decide which filter must be called depending on the context status.
>
> (Note that the controller should also decide which message to call, for instance, it can decide that it has to call a messageReceived() because it's caller was processing a messageReceived())
I feel that, for the most part, we all have been doing a lot of discussions without any mock implementations of real protocols to help us gauge our API decisions. Our tendency is to dive into the implementation details and then shoehorn protocols into the resultant API. This is why Mina 2 is so bloated and daunting. I'd like to see lots of little sandbox branches where people show what protocol implementations would end up looking like for the feature they are proposing. It's a fantastic way to gauge API design differences.
To that end I invite everyone to flesh out, as I am doing in my sandbox branch, the following protocols:
Link state protocol - implementation of [1]
Group protocol - [2]
Paxos - ideally would use the above protocols
SSL
Checksum
MUX/DEMUX
[1] http://caltechparadise.library.caltech.edu/32/
[2] http://authors.library.caltech.edu/5410/
Regards,
Alan
Re: [MINA 3.0] filter chains
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 8/26/11 6:16 PM, Alan D. Cabrera wrote:
> On Aug 26, 2011, at 9:10 AM, Emmanuel Lecharny wrote:
>
>> On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
>>> On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
>>>
>>>
>>> <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.
> Ok, now I know where you're coming from. For me I have a map of chains
>
> Map<State, Chain> states = …
> State current;
What is Chain in this context ?
I don't think it's enough to build the demux. We probably would need
something like :
Map<Status, Filter> filterMap = ...
Map<Filter, Map<Status, Filter>> fsmMap = ...
( I keep Filter, but a Filter for us is a State in a FSM)
otherwise, the controller can't select the next Filter without having a
clue about the context
>
> void send(T message)
> {
> Chain chain = states.get(current);
> current = chain.send(message);
> }
What I have in mind is much more something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
controller.callNextFilter( context, currentFilter );
... // do something after the call
}
and in controller :
void callNextFilter( Context context, Filter currentFilter )
{
Status status = context.getStatus();
Map<Status, Filter> map = fsmMap.get( currentFilter );
Filter nextFilter = map.get( status );
nextFilter.messageReceived( context );
}
The controller will decide which filter must be called depending on the
context status.
(Note that the controller should also decide which message to call, for
instance, it can decide that it has to call a messageReceived() because
it's caller was processing a messageReceived())
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Aug 26, 2011, at 9:10 AM, Emmanuel Lecharny 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<el...@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<li...@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.
Ok, now I know where you're coming from. For me I have a map of chains
Map<State, Chain> states = …
State current;
void send(T message)
{
Chain chain = states.get(current);
current = chain.send(message);
}
So the effect is
[outside filter] -> [FSM [current chain] ] -> [outside filter]
Re: [MINA 3.0] filter chains
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Aug 26, 2011, at 9:15 AM, Julien Vermillard wrote:
> On Fri, Aug 26, 2011 at 6:10 PM, Emmanuel Lecharny <el...@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<el...@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<li...@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.
If you think it's useful to work out lower level details while the API design is still happening, cool. It may happen that decisions about the API will affect your work. With that said, I think that it would be interesting to see what can be done for an NIO loop that is different from the existing Mina ones.
Regards,
Alan
Re: [MINA 3.0] filter chains
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 8/26/11 6:15 PM, Julien Vermillard wrote:
> On Fri, Aug 26, 2011 at 6:10 PM, Emmanuel Lecharny<el...@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<el...@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<li...@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
Re: [MINA 3.0] filter chains
Posted by Julien Vermillard <jv...@gmail.com>.
On Fri, Aug 26, 2011 at 6:10 PM, Emmanuel Lecharny <el...@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<el...@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<li...@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.
Julien
Re: [MINA 3.0] filter chains
Posted by Emmanuel Lecharny <el...@gmail.com>.
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<el...@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<li...@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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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<el...@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<li...@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?
Regards,
Alan
Re: [MINA 3.0] filter chains
Posted by Emmanuel Lecharny <el...@gmail.com>.
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<el...@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<li...@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>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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<el...@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<li...@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. The message would run its course through the chain and then the next state would be set. Otherwise things become intractable.
Regards,
Alan
Re: [MINA 3.0] filter chains
Posted by Emmanuel Lecharny <el...@gmail.com>.
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<el...@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<li...@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...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
Posted by Julien Vermillard <jv...@gmail.com>.
On Fri, Aug 26, 2011 at 4:28 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>
>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny <el...@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<li...@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 think we need to avoid complex feature like graph. IMHO server in
MINA is a codec and an handler 90% of the time. Someone have a use
case which could use filter graph with MINA ?
Re: [MINA 3.0] filter chains
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny <el...@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<li...@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.
Regards,
Alan
Re: [MINA 3.0] filter chains
Posted by Julien Vermillard <jv...@gmail.com>.
On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny <el...@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<li...@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
Julien
Re: [MINA 3.0] filter chains
Posted by Emmanuel Lecharny <el...@gmail.com>.
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<li...@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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re : [MINA 3.0] filter chains
Posted by Edouard De Oliveira <do...@yahoo.fr>.
On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera <li...@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?
>Regards,
>Alan
On my side, besides the @ fsm declaration api (which may be impossible to use as i think it fixes the position of a filter in the chain which is not universal)
i wrote a simple api i'd like your thoughts on (using the type of syntax used in hibernate criteria) :
FSMState init = getInitialState();
FSMState b = init.linksTo(FSMStateB.class);
b.linksTo(FSMStateZ.class);
FSMState d = b.linksTo(FSMStateC.class).linksTo(FSMStateD.class);
d.linksTo(FSMStateE.class);
d.linksTo(FSMStateF.class);
which represents obviously :
INIT -> B -> Z
|-> C -> D -> E
|-> F
wdyt ?
Re: [MINA 3.0] filter chains
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera <li...@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?
Regards,
Alan
Re: [MINA 3.0] filter chains
Posted by Julien Vermillard <jv...@gmail.com>.
On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera <li...@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();
> IoFilter 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 ?
About the "filters feed into one or one filter feeds two filters", do
you have a concrete use case in mind for that ?
Re: [MINA 3.0] filter chains
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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();
IoFilter 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);
Re: Re : Re : [MINA 3.0] filter chains
Posted by Julien Vermillard <jv...@gmail.com>.
On Thu, Aug 25, 2011 at 2:29 PM, Edouard De Oliveira
<do...@yahoo.fr> wrote:
> On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira
>
> <do...@yahoo.fr> wrote:
>>
>>
>> On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
>>> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
>>>
>>>
>>>> But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate a much more complicated FSM that the coder would have to describe with code ... better ?) ?
>>>>
>>>> Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ?
>>>
>>> There's no reason why one could not have a chain of FSMs. You get the exact same behavior with less framework code.
>>
>>>The reason why MINA 1 and 2 has a chain is unclear. One possible explainaition is that MINA was supposed to implement the SEDA >architecture (each filter communicate with the next filter using a queue, and as this architecture is supposed to spread filters on more than >one computer, then it's easier to implement it using a chain. Well, that's my perception. One other reason was the lack of vision about the >possible use cases. 6 years in restrospect, I do think that this need never surfaced...
>> With the growing of the base code it's easier just by looking at what exists to find some use case one would not have though of at this time
>>
>>>The more I think about this problem, the more I think that FSM is the way to go :
>>>- we don't add filters dynamically on a created session
>>
>>
>>>- we *always* know which filter we will call whatever state we are : it's a protocol we are handling, it's well defined !
>> +1 : it's just that it will require much more preliminary toughts to start coding a server -> that's our good practices promoting thing
>>
>>>- debugging will be easier
>> i won't be so categorical about this as whatever graph type you use to describe your 'chain' it will still be session/data dependent
>>
>>>- we won't have to use some strange Mutiplexer filter in order to call one filter or another depending on the message we are dealing with, like >it's currently the case in MINA 2
>> not so strange as it is a well known design pattern (Command Pattern)
>>
>>>- coding a protocol will be easier
>> we have to make basic servers easier (or as easy as before) too
>>
>>>- we can define @ to declare the FSM, making the developper's life easier (an idea that needs to be developed...)
>>
>>>i was also planning on some @ (like @unique to limit the presence of a filter in the chain or some more generic one that would provide the name and the unicity of the filter for Mina 2 obviously)
>>
>>>for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated FSM declaration code and found this interesting article >which could be a good base to start with :
>>>http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html
>>
>>
>> You can find a fast hack at the following pastebin url which shows how i changed the original code of the article to add data dependent transitions :
>> http://pastebin.com/CjXjJ2Q1
>>
>>
>>>Do we all agree on that ?
>>>There's lot of momentum on this solution so it should be given at least a try obviously
>>
>
>>+1
>>it's hard for me to figure if it's going to be the solution witout a
>>more complex example implementation
>
>
> it's far from being an implementation it's just a basic poc that a fsm can be built with @
>
>
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(...);