On Sat, Oct 11, 2014 at 8:24 AM, Emmanuel Lécharny <[email protected]> wrote:
> Le 08/10/14 11:45, Jeff MAURY a écrit : > > On Wed, Oct 8, 2014 at 10:33 AM, Emmanuel Lécharny <[email protected]> > > wrote: > > > >> Le 07/10/14 23:37, Jeff MAURY a écrit : > >>> Hello, > >>> > >>> as I'm working on the SSL part this time and more specifically on the > >>> handshake/rehandshake processing, I have a couple of questions and some > >>> infos to share: > >>> > >>> - I've added 3 more methods in IoHandler to reflect handshake > related > >>> event: handshakeStarted, handshakeCompleted and secureClosed. I've > >> added > >>> them as well to IoFilter but I don't quite understand the philosophy > >> as > >>> some method have a chain controller to call the next filter and some > >> not > >> The idea behind the chain of filters is that any event is propagated up > >> to the final filter (ie, the Iohandler) by each filter. If one filter > >> decide not to propagate the event, then obviously the IoHandler will not > >> receive it. This is thus to the Filter implementer to be sure it does > >> propagate the event to teh next filter. If it does not, this is either a > >> mistake, or a decision that has to be heavily and carefully thought. > >> > >> The pb is to delegate this responsability to the filter. It would be > >> easier if the controller was to propagate the event further without > >> expecting teh filter to do so. That woudl require some careful rework of > >> the controller, as in some case (like errors, exceptions, etc) we don't > >> want to propagate the event. > >> > >> In some other cases, we simply want the filter to handle the event > >> propagation (typically this is the case for the MessageReceived when we > >> are using a decoder filter : there is no mean to propagate the event > >> automatically if a full message has not been decocded). > >> > >> This is definitively something we want to think about. > >> > > What I didn't understand is that not all of IOFilter method signatures > have > > a ChainController so I did not understand how they can decide to swallow > > the event or not. > > Not sure what you mean by "not all of IOFilter method signatures have a > ChainController" in Mina 2.0 context. > > The IoFilter class has 3 sets of methods : > - methods that propagate an event : > o exceptionCaugth > o filterClose > o filterWrite > o inputClose > o messageReceived > o messageSent > o sessionClosed > o sessionCreated > o sessionIdle > o sessionOpened > I don't agree for MINA 3. See https://github.com/apache/mina/blob/trunk/core/src/main/java/org/apache/mina/api/IoFilter.java > > Those methods have a NextFilter parameter, which is the filter that > will receive the event, should the current filter decide to propagate > it. This can be seen in, for instance, the BlackListFilter : > > public void messageSent(NextFilter nextFilter, IoSession session, > WriteRequest writeRequest) throws Exception { > if (!isBlocked(session)) { > // forward if not blocked > nextFilter.messageSent(session, writeRequest); > } else { > blockSession(session); > } > } > > > - methods that manage the chain manipulation : > o onPreAdd > o onPostAdd > o onPreRemove > o onPostRemove > > Those methods just react on the addition or removal of the current > filter from the session chain. > > - general methods : > o init > o destroy > > Those methods are called when the filter is created or destroyed. > > Note that all the filter extends the IoFilterAdapter which already have > a default implementation for all those methods (hence it should be an > abstract method, IMO). > > Is that what you wanted to get some clarification on ? > > > > >>> - In order to support rehandshaking et being efficient, we must keep > >> the > >>> same SSLEngine. > >> Ok, makes sense. > >>> So my idea to start a new handshake was to reuse what we > >>> have today through the initSecure method: if the SSLContext is null, > >> I don't see how we can have a null SSLContext, as we create it before > >> creating the SSLFilter, and there is a check for nullity in this > >> constructor : > >> > >> public SslFilter(SSLContext sslContext, boolean autoStart) { > >> if (sslContext == null) { > >> throw new IllegalArgumentException("sslContext"); > >> } > >> > >> Assuming we always have a not null SSLContext, how does it translates in > >> your proposed algorithm ? >> > > I was mentioning the SSLContext that is the argument of the initSecure > > method. Please note that in 3.0, there is no more SSLFilter as SSL > handling > > has been moved to core. > > So my idea is that if no SSLContext is given to initSecure and SSLHandler > > is attached to the session, we keep the same underlying SSLEngine and we > > start a new handshake > > I see. You propose to handle the handshake re-negociation through a call > to a newly added method called initSecure( SslContext ) in MINA 2, is > that correct ? > No, I was talking about MINA3 and about the semantic of this existing method. Jeff -- Jeff MAURY "Legacy code" often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
