I don't think there is any other way to achieve this other than handling it in the filter chain (like you already do) (Indeed I have implemented a similar handshake mechanism 2 years back)
On Thu, Jun 9, 2011 at 7:55 PM, Shaun Senecal <[email protected]> wrote: > Hi > > I'm trying to implement an encryption layer for UDP (due to the lack of a > DTLS implementation for java right now), and my first attempt was to put it > into a filter like SslFilter. It works, but the implementation is ugly as I > need to keep track of specific NextFilter instances so that handshake > messages dont end up going through the regular filter chain. Would this be > better implemented as something other than a filter? > > Currently, my filter chains look something like this: > > 1. DALS ProtocolCodecFilter (encodes/decodes handshake and encrypted > messages) > 2. DALS Filter (provides encryption/decryption/reliable handshake) > 3. user's ProtocolCodecFilter (this would be the end-user's codec, so I have > no control of what it is) > 4. any other filters the end user see's fit to add > > The DALS Filter needs to keep a reference to the DALS ProtocolCodecFilter so > that it can write handshake messages without exceptions being thrown by the > user's ProtocolCodecFilter because it is unable to encode the handshake > messages. Since I am manipulating the filter chain it seems like maybe this > functionality should be pulled out of the chain and put somewhere else, but > I'm not sure where. > > Any ideas? > -- Kiran Ayyagari
