On Aug 19, 2011, at 4:53 PM, Emmanuel Lecharny wrote: > On 8/19/11 2:29 PM, Alan D. Cabrera wrote: >> On Aug 19, 2011, at 5:16 AM, Emmanuel Lecharny wrote: >> >>> On 8/19/11 1:55 PM, Alan D. Cabrera wrote: >>>> On Aug 19, 2011, at 4:16 AM, Julien Vermillard wrote: >>>> >>>>> Hi, >>>>> I implemented some really simple chain for MINA 3 based on a list of >>>>> chain processed by a filter chain. >>>>> >>>>> The implementation is very simple, sounded like a good idea : >>>>> http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/filterchain/DefaultIoFilterChain.java >>>>> >>>>> But when i started implementing an HTTP codec I started to see the >>>>> real design issues. >>>>> The problem is when you need to produce more than one object during a >>>>> filter processing, like when you find more than one PDU in a >>>>> ByteBuffer. >>>>> >>>>> We could change IoFilter method : >>>>> Object messageReceived(IoSession session, Object message); >>>>> To : >>>>> List<Object> messageReceived(IoSession session, Object message); >>>>> >>>>> But starting to use collection here sound like an overkill and not >>>>> really a nice idea if we want to keep the memory usage low enough. >>>>> >>>>> So I'm scraping the current implementation, I'm going to try something >>>>> else suggested by Emmanuel : >>>>> When a filter want to call the next filter, he ask it to the filter >>>>> controller (aka the FilterChain). Let's see if it's going somewhere >>>>> this time ;) >>>> I ran into a different scenario that dictated the same result. For me, >>>> often times when a message is sent or received no message is passed on so >>>> my protocol had to always return a null. This always seemed awkward to >>>> me. Also, then that dictated that I had to check for nulls in the >>>> framework, also not so good. >>>> >>>> Take a look at my class org.apache.mina.link.UpState to see what I mean. >>> We should not compare filters and pipes. Think about the whole mechanism as >>> if it was a state machine, because it is. The only relation between two >>> states are those dicatetd by the transition we allow. We don't transite >>> from one state to another one randomly, so are the data passed from one >>> state to another : they are well known by both the initial and the final >>> states. >> I'm not sure that I'm following. What is this data that you speak of? > > Let me clarify my thought : I'm talking about any data transiting from one > filter to another. If it's from the socket to the first filter, then it's a > ByteBuffer. If it's between the decoder and the Handler, then it's a protocol > message. Etc. >> >>> We should then make no general presumption about the received and sent >>> data. If one state does not require anything, fine : the caller will know >>> it. OTOH, if we can have multiple data to send to the next state, then we >>> just have to loop and call as many times the next step as necessary. >> I'm not sure that I'm following. Who is the caller and why does he need to >> know all this? > > Simply because the kind of data the receiver will process has to be a data it > *can* handle. A decoder is supposed to receive some bytes and transform them > to a message. But we can also imagine a 2 layers decoder, and then the second > decoder will expect a message, not some bytes. > > One example : in LDAP, we received PDU, which contains TLVs > (Type/length/value). Then we transform those TLVs into LDAP message. > The first decoder will transform bytes to TLVs; > The second decoder will transform the TLVs to LDAP messages (searchRequest, > etc); > > Here, the second decoder won't be able to do anything if it receives some > ByteBuffer, so the caller (the first decoder) *must* know what the second > decoder will accept, otherwise you'll get some nasty exception. > > Is it clearer?
Yes, filters in a chain must pass messages of a known type between themselves. There's the added dimension of endpoint cardinality, which this thread discusses, of zero, one, many that can occur on both ends of a link in the chain. > PS : That's the problem when both of us are not english fluent... When I > write a mail (a message), I'm losing some context, and you can't decode > exactly what I had in mind when I wrote it. Sorry for that :/ No worries. I, as an American, struggle to keep my english fluent as well. ;) Regards, Alan
