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