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