Hi Jonathan,

there are two aspects to consider:

- first the establishemnt of the secured session
- second the standard exchange of data when the session has been secured.

In the first case, we should *never* have any write done by the IoHandler, or those writes should be enqueued until the session has been secured. Here, the upstream filters should not be aware that the session has been secured or not (all in all, filters are supposed to be independenct)

In the second case, the SslFilter is responsible for handling the encoding and decoding of the data, regardless of what the upper filters are doing

So there should not be any assumption made on what wcould or should do the upstream filters (that's because anyone can add a filter, and we should not force the implementors to take care of unerlying filters constraints).

So the best way to deal with writes while the Secured session establishment is ongoing is to enqueue the writes until the session is secured. It adds some complexity, but it's safe for the full stack (reads are a different beast: we have to assume that we can only read Handshake packets until the HS is completed)

I guess it fits with what you have in mind.


On 17/02/2024 04:12, Jonathan Valliere wrote:
I was thinking this over last weekend….

If I simply removed the synchronization then there COULD be several
incoming data corruption problems unless the upstream filters/ processors
MUST guarantee FIFO of the data stream.

What I would have todo is push OR copy the incoming buffer into a Queue
then perform processing off the head of that Queue.  Essentially, do the
same as the mEncodeQueue but for Decodes.  The lock would then only be held
when processing data off of that Decode queue.  Following this pattern, I
could probably remove both the READ and WRITE synchronization blocks.

My understanding, for MINA, that the assumption is that it SHOULD be safe
to hold on to any object passed into a Filter since object lifecycles
SHOULD be controlled by the VM and not the User’s code.

If we’re in agreement, I can make the change.


On Feb 10, 2024 at 2:14:01 PM, Kishore Mokkarala <[email protected]>
wrote:

Any time line for removing synchronization block in SSLFilter?

On Sat, 10 Feb, 2024, 9:48 pm Emmanuel Lécharny, <[email protected]>
wrote:

Netty is not Apache, but Eclipse.


We are discussing the error at the moment, trying to move away the

SSLFilter synchronized block.


On 10/02/2024 08:10, Kishore Mokkarala wrote:

We had to revert mina version to 2.0.25 from 2.2.1 to make it work in

production and  trying for other alternatives like apache netty.



On Fri, 9 Feb, 2024, 1:59 pm Emmanuel Lécharny, <[email protected]

<mailto:[email protected]>> wrote:



     Hi Jonathan,



     in this very case, I think there is a race condition when using the

     SSLFilter in conjonction with the StateMachine filter.



     On 09/02/2024 05:33, Jonathan Valliere wrote:

      >   No, you should not have to create multiple instances.  The

     necessary

      > stateful data is saved to the Connection.

      >

      >

      > On Feb 1, 2024 at 5:22:36 AM, Kishore Mokkarala

     <[email protected] <mailto:[email protected]>>

      > wrote:

      >

      >> Any response would be greatly appreciated.

      >> ------------------------------------------

      >> M.V.S.Kishore

      >> 91-9886412814

      >>

      >>

      >> On Wed, 31 Jan 2024 at 22:17, Kishore Mokkarala

     <[email protected] <mailto:[email protected]>>

      >> wrote:

      >>

      >> Hi Emmanuel,

      >>

      >>

      >> Do we need to create a new instance of SSLFilter per tcp ip

     connection or

      >>

      >> can we reuse it ?

      >>

      >>

      >> For example, do we need to repeat the same code for each tcp ip

     connection

      >>

      >> ?

      >>

      >>

      >> *Approach 1:*

      >>

      >> for(int i=0;i< 500;i++)

      >>

      >> {

      >>

      >> NioSocketConnector connector = new NioSocketConnector();

      >>

      >> connector.getFilterChain().addLast("LoggingFilter",

      >>

      >> G10CaptureService.loggingFilter);

      >>

      >> connector.getFilterChain().addLast("codecFilter",

      >>

      >> G10CaptureService.probeCodecFilter);

      >>

      >> connector.getFilterChain().addLast("executorFilter",

      >>

      >> G10CaptureService.executorFilter);

      >>

      >> connector.getFilterChain().addLast("gpbMessageFilter",

      >>

      >> G10CaptureService.gpbMessageFilter);

      >>

      >> connector.getFilterChain().addLast("keepAliveFilter",

      >>

      >> G10CaptureService.keepAliveFilter);

      >>

      >> SslFilter sslFilter;

      >>

      >> try {

      >>

      >> SSLContext sslContext = TLSUtil.getSSLContext();

      >>

      >> sslFilter = new CustomSslFilter(sslContext);

      >>

      >> connector.getFilterChain().addFirst("sslFilter", sslFilter);

      >>

      >> } catch (Exception e) {

      >>

      >> e.printStackTrace();

      >>

      >> LOG.error("Exception during creating SSL context..." +

      >>

      >> XError.getStackTrace(e));

      >>

      >> }

      >>

      >> //io handler creation

      >>

      >> StateMachine stateMachine =

      >>

      >>

StateMachineFactory.getInstance(IoHandlerTransition.class).create(

      >>

      >>                  G10MinaClient.CONNECTED, new

     G10MinaClient(processor));

      >>

      >>

      >>          IoHandler ioHandler = new

      >>

      >> StateMachineProxyBuilder().setStateContextLookup(

      >>

      >>                  new IoSessionStateContextLookup(new

     StateContextFactory() {

      >>

      >>                      @Override

      >>

      >>                      public StateContext create() {

      >>

      >>                          final G10StateContext stateContext = new

      >>

      >> G10StateContext();

      >>

      >>                          stateContext.setStartedTime(new Date());

      >>

      >>                          LOG.info("G10StateContext initialized

at:{}

      >>

      >> ",System.currentTimeMillis());

      >>

      >>                          return stateContext;

      >>

      >>                      }

      >>

      >>                  })).create(IoHandler.class, stateMachine);

      >>

      >> connector.setHandler(ioHandler);

      >>

      >> connector.connect(primaryAddress);

      >>

      >> connectFuture.awaitUninterruptibly();

      >>

      >> if (connectFuture.isConnected()) {

      >>

      >> IoSession session = connectFuture.getSession();

      >>

      >> // Do something with the session if needed

      >>

      >> } else {

      >>

      >> System.err.println("Connection failed for iteration: " + i);

      >>

      >> }

      >>

      >> }

      >>

      >>

      >> *Approach 2:*

      >>

      >> Reuse the generic connector implemented above for opening all

TCP/IP

      >>

      >> connections.

      >>

      >> //just do the below for getting connections for example

      >>

      >> NioSocketConnector connector = new NioSocketConnector();

      >>

      >> //filter chain creation

      >>

      >> //add SSLFilter to filer chain

      >>

      >>

      >> for(int i=0;i< 500;i++)

      >>

      >> {

      >>

      >> ConnectFuture connectFuture = connector.connect(serverAddress);

      >>

      >> connectFuture.awaitUninterruptibly();

      >>

      >> if (connectFuture.isConnected()) {

      >>

      >> IoSession session = connectFuture.getSession();

      >>

      >> // Do something with the session if needed

      >>

      >> } else {

      >>

      >> System.err.println("Connection failed for iteration: " + i);

      >>

      >> }

      >>

      >> }

      >>

      >>

      >> Which approach is better ?

      >>

      >>

      >> Regards,

      >>

      >> ------------------------------------------

      >>

      >> M.V.S.Kishore

      >>

      >> 91-9886412814

      >>

      >>

      >>

      >



     --

     *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61

     [email protected] <mailto:[email protected]>



     ---------------------------------------------------------------------

     To unsubscribe, e-mail: [email protected]

     <mailto:[email protected]>

     For additional commands, e-mail: [email protected]

     <mailto:[email protected]>




--

*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61

[email protected]





--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
[email protected]

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to