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! >
