directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Raess <>
Subject Re: [mina] protocol implementation question
Date Fri, 17 Feb 2006 20:12:12 GMT

On 17.02.2006, at 08:32, Niklas Therning wrote:

> Simon Raess wrote:
>> hi
>> I'm trying to implement the BEEP protocol (RFC3080) on top of  
>> Mina.  Now, I have several questions relating to the implementation.
>> I've implemented a basic IoFilter that implements framing  
>> according  to the BEEP protocol. The next filter is supposed to  
>> implement the  transport specific mapping for TCP (RFC3081). This  
>> mapping defines a  sliding window mechanism for BEEP channels. The  
>> TCP mapping filter  needs to send a message back to the other side  
>> to acknowledge  messages (i.e. slide the window). An IoFilter has  
>> access to the next  filter. However, it does not have access to  
>> the previous filter (to  send the message). I know, I could use  
>> the IoSession to send a  message, but then it starts at the top of  
>> the filter chain  (correct?), i.e. it passes all the filters in  
>> the chain, even the  ones above the current filter (which is not  
>> really what I'd like to do).
> Actually, you do have access to the previous filter. Just call  
> nextFilter.filterWrite() in your filter if you need to write  
> messages. You see, NextFilter is the next filter for a particular  
> operation. In the case of filterWrite the next filter is actually  
> the filter *before* the current filter while for all other  
> operations (sessionOpened, messageReceived, etc) the next filter is  
> the filter *after* the current filter. This is always true no  
> matter which callback was called in your filter implementation.
> I know it might be a bit confusing. :)

Sort of, but once you know it, it seems logical. :)

>> I'm wondering whether it is "a good idea" to send messages from   
>> within the filters. Has anybody done that? Is it possible to pass  
>> a  message to the previous filter when receiving messages? Or  
>> should I  handle these issues in the protocol handler, possibly  
>> using  IoHandlerCommand or a layered protocol handler stack? Any  
>> other  suggestion, ideas?
> Yes, it's very good idea. As I said SSLFilter works this way, as  
> does StreamWriteFilter. In fact, have a look at StreamWriteFilter.  
> It's a very good and easy to understand example of how it could be  
> done.
> /Niklas

I'll have a look at the classes you suggested.

Thanks for the hints!

View raw message