Ya, I thought about doing that, but I wanted this to be a "general purpose" filter, which means I needed a solution that didnt require modifications to any downstream filters.
On Fri, May 27, 2011 at 8:06 PM, Abhijit Bhatode < [email protected]> wrote: > I was facing a simiilar issue: My application required processing handshake > messages that should not be passed to ProtocolEncoder/Decoder. I maintained > the state in IoSession and accordingly inferred whether to encode or decode > the message. > ________________________________________ > From: Shaun Senecal [[email protected]] > Sent: Friday, May 27, 2011 4:24 PM > To: [email protected] > Subject: Re: skipping certain filters in a chain to allow handling UDP > encryption handshake messages > > I take it back. Hopefully I didnt waste anyone's time with this. > > The solution seems to have been that I needed to swap my 2 DTLS filters and > then when I am writing "handshake" messages, I dont write them to the > IoSession directly, but instead I write them to the DTLS Codec filter > directly. > > The chain now looks like: > DTLS Protocol Codec ---> DTLSFilter ---> TextLineCodec --> Logger > > and DTLSFilter hangs on to a reference to DTLS Protocol Codec so it can > send > the Handshake messages without worrying about the other filters messing > with > it. > > If I am able to get this solution working in a reasonable manner, I will > post it somewhere (and reply to this thread with its location) so that > others might be able to use this UDP encryption thingy. I just have it > passing simple encrypted strings right now though (thus the TextLineCodec), > so dont hold you breath that it will be anytime soon :) > > > > On Fri, May 27, 2011 at 5:52 PM, Shaun Senecal <[email protected]> wrote: > > > I'm using MINA 2.0.2 to implement a filter which adds encryption to UDP > > messages (basically a mini-DTLS). The problem I'm having is that I was > > hoping to be able to simply place a ProtocolCodecFilter on the filter > chain > > to handle these messages, but when I send out one of these messages it > gets > > processed by every other filter in the chain which is resulting in my > > internal handshake messages being encoded by the TextLineCodec I have > later > > on in the chain. > > > > The chain looks like this: > > DTLSFilter ---> DTLS Protocol Codec ---> TextLineCodec --> Logger > > > > When I initiate the handshake from the DTLSFilter, it writes the > > HandshakeMessage to the IoSession, which promptly passed it for > processing > > through the chain in reverse order. This results in the TextLineCodec > > "encoding" my HandshakeMessage before my DTLS Protocol Codec gets a > chance > > to. Is there a way I can simply disable the last N codecs during the > > handshake process and re-enable them afterwards? > > > > I noticed some discussions about a state machine based filter process in > > MINA 3.0 which sounds like it might be what I want, but thats not > possible > > in 2.0 AFAIK. I also noticed that SslFilter isnt using this approach, so > > perhaps its not possible to have an out-of-band set of messages to > perform > > the handshaking and I should just try to repeat what SslFilter does! > > > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is > the property of Persistent Systems Ltd. It is intended only for the use of > the individual or entity to which it is addressed. If you are not the > intended recipient, you are not authorized to read, retain, copy, print, > distribute or use this message. If you have received this communication in > error, please notify the sender and delete all copies of this message. > Persistent Systems Ltd. does not accept any liability for virus infected > mails. > >
