You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@mina.apache.org by Simon Trudeau <st...@bluetreewireless.com> on 2008/03/25 15:36:39 UTC
IoFuture and OnConnect event question
I am currently writing an application who establishes a connection with
a legacy server and negotiates a custom password protection. I
implemented my password protection negotiation scheme as an IoFilter
since it is the server who instigates the password exchange. Since a
connection is not really considered complete (for the purpose of sending
ordinary messages) until the password has been negotiated, it there a
way to delay the ConnectListener.operationComplete, until my password
negotiation IoFilter has run?
More generally, when are the IoFutureListener invoked? Before or after
the IoFilters?
I guess I could intercept in my Password Negotiation IoFilter the
sessionOpened event until the right password has been sent and accepted
by the server, after which I could let the sessionOpened propagate up to
the IoHandler...
What do you think?
Thanks,
Simon
RE: IoFuture and OnConnect event question
Posted by Simon Trudeau <st...@bluetreewireless.com>.
Euhm, very interesting... I didn't knew about the IoSessionInitializer, I guess it adresses my problem perfectly. I'll give the JIRA as further reference for the readers:
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552319
Thanks Trustin,
Simon
-----Original Message-----
From: "이희승 (Trustin Lee) [mailto:trustin@gmail.com]
Sent: April-03-08 5:09 AM
To: users@mina.apache.org
Subject: Re: IoFuture and OnConnect event question
In such a case you could specify IoSessionInitializer in your connect() call. WDYT?
HTH,
Simon Trudeau wrote:
> Just a few precision for the readers out there reading this thread :.) The filter in mina 2 is named SessionAttributeInitializingFilter and not IoSessionAttributeInitializingFilter. Details, but it's good to know when looking for it in the API.
>
> Having a filter is good, but the chicken and egg question remains.
>
> Adding a SessionAttributeInitializingFilter to the connector will allow to initialize session parameter which are common to all session. Which is nice, but not good enough for what I'm trying to achieve. I'm sharing a connector among many clients. That is why I need to initialize session specific attributes and that is why it can't be done at the "connector" level. To initialize session specific attributes at the session level, first I need to obtain a session and here lies the chicken and egg problem! I cannot add a SessionAttributeInitializingFilter to the session filter chain until I optain a session! It would be nice to have a sort of connect future callback handler that would get invoked prior to the filter chain. This way we could set session attributes (user name and password, for example) prior to having the filters run on the connection event.
>
> Currently, as a workaround, I initialize my connection credentials and trigger the sending of messages when the session gets created using the an IoFutureListener for the connectFuture event, but I buffer the messages sent on the session in my custom passwordProtectionFilter until the password exchange finishes. This follows the scheme currently used by SSLFilter and SSLHandler.
>
>
> Simon
> -----Original Message-----
> From: "이희승 (Trustin Lee) [mailto:trustin@gmail.com]
> Sent: April-01-08 11:44 PM
> To: Simon Trudeau
> Cc: users@mina.apache.org
> Subject: Re: IoFuture and OnConnect event question
>
> Hi Simon,
>
> There's a filter called IoSessionAttributeInitializingFilter. You can insert that filter at the first place of the filter chain to add some attributes before events hit your filters.
>
> HTH,
>
> Simon Trudeau wrote:
>> Thanks for the info, it looks very promising.
>>
>> I would really like to delay the invocation of the sessionCreated after the password has been negotiated. Unfortunately, I use the IoFutureListener to be notified of when an IoSession gets created to set the credentials that are needed for the password negotiation. So I was wondering, how can I pass connection specific information (user name, password) to my PasswordNegotiationFilter when I don't even have a hold of an IoSession. (I only obtain the IoSession after the connectFuture completes. This is not good because if the connectFuture only completes after the password has been negotiated, the password negotiation data will only get initialized too late).
>>
>> Chicken and Egg Question:
>>
>> So how can I instantiate session specific information such as user name and password so it can get used in my IoFilters if I intend to intercept the connectFuture until the password has been negotiated?
>>
>> What do you think?
>>
>> Thanks for your help! :.)
>>
>> P.S.:
>> I have a vague idea of how to do it... Don't intercept the connectFuture in the password negotiation filter, initialize session specific information in the IoSession in the callback handler of the connectFuture. Have the password negotiation filter send a virtual message which will be intercepted by a ReadFuture's callback handler, and execute some logic in the ReadFuture's callback listener... What do you think?
>>
>>
>> Thanks,
>>
>> Simon
>>
>> -----Original Message-----
>> From: 이희승 (Trustin Lee) [mailto:trustin@gmail.com]
>> Sent: March-31-08 11:41 AM
>> To: users@mina.apache.org
>> Subject: Re: IoFuture and OnConnect event question
>>
>> Hi Simon,
>>
>> You already have posted an updated question, but let me answer again
>> from somewhat different aspect.
>>
>> On Tue, 2008-03-25 at 23:36 +0900, Simon Trudeau wrote:
>>> I am currently writing an application who establishes a connection
>>> with a legacy server and negotiates a custom password protection. I
>>> implemented my password protection negotiation scheme as an IoFilter
>>> since it is the server who instigates the password exchange. Since a
>>> connection is not really considered complete (for the purpose of
>>> sending ordinary messages) until the password has been negotiated,
>>> it there a way to delay the ConnectListener.operationComplete, until
>>> my password negotiation IoFilter has run?
>> You can intercept sessionCreated (sessionOpened in 1.x) event and
>> stop propagation of sessionCreated, sessionOpened, messageReceived
>> and store the all the intercepted events to some data structure such as queue.
>> When a client is authenticated, you can call nextFilter.<event>()
>> method for all previously intercepted and queued events to continue
>> the connection. ConnectFuture will not be triggered until
>> sessionCreated (sessionOpened in 1.x) event is propagated to
>> IoHandler, so this should work as you expected.
>>
>>> More generally, when are the IoFutureListener invoked? Before or
>>> after the IoFilters?
>> ConnectFuture notifies its listeners right after
>> IoHandler.sessionCreated() (sessionOpened in 1.x) is invoked.
>>
>> Other futures such as WriteFuture and CloseFuture notify the
>> completion of operation immediately. I can be invoked both before
>> and after the IoFilters - they are independent from each other.
>>
>>> I guess I could intercept in my Password Negotiation IoFilter the
>>> sessionOpened event until the right password has been sent and
>>> accepted by the server, after which I could let the sessionOpened
>>> propagate up to the IoHandler...
>>>
>>> What do you think?
>> Yes, you can do that as I mentioned. You might want to take a look
>> into the SslFilter.java because it does something similar.
>>
>
> --
> Trustin Lee - Principal Software Engineer, JBoss, Red Hat
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
>
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: IoFuture and OnConnect event question
Posted by 이희승 (Trustin Lee) <t...@gmail.com>.
In such a case you could specify IoSessionInitializer in your connect()
call. WDYT?
HTH,
Simon Trudeau wrote:
> Just a few precision for the readers out there reading this thread :.) The filter in mina 2 is named SessionAttributeInitializingFilter and not IoSessionAttributeInitializingFilter. Details, but it's good to know when looking for it in the API.
>
> Having a filter is good, but the chicken and egg question remains.
>
> Adding a SessionAttributeInitializingFilter to the connector will allow to initialize session parameter which are common to all session. Which is nice, but not good enough for what I'm trying to achieve. I'm sharing a connector among many clients. That is why I need to initialize session specific attributes and that is why it can't be done at the "connector" level. To initialize session specific attributes at the session level, first I need to obtain a session and here lies the chicken and egg problem! I cannot add a SessionAttributeInitializingFilter to the session filter chain until I optain a session! It would be nice to have a sort of connect future callback handler that would get invoked prior to the filter chain. This way we could set session attributes (user name and password, for example) prior to having the filters run on the connection event.
>
> Currently, as a workaround, I initialize my connection credentials and trigger the sending of messages when the session gets created using the an IoFutureListener for the connectFuture event, but I buffer the messages sent on the session in my custom passwordProtectionFilter until the password exchange finishes. This follows the scheme currently used by SSLFilter and SSLHandler.
>
>
> Simon
> -----Original Message-----
> From: "이희승 (Trustin Lee) [mailto:trustin@gmail.com]
> Sent: April-01-08 11:44 PM
> To: Simon Trudeau
> Cc: users@mina.apache.org
> Subject: Re: IoFuture and OnConnect event question
>
> Hi Simon,
>
> There's a filter called IoSessionAttributeInitializingFilter. You can insert that filter at the first place of the filter chain to add some attributes before events hit your filters.
>
> HTH,
>
> Simon Trudeau wrote:
>> Thanks for the info, it looks very promising.
>>
>> I would really like to delay the invocation of the sessionCreated after the password has been negotiated. Unfortunately, I use the IoFutureListener to be notified of when an IoSession gets created to set the credentials that are needed for the password negotiation. So I was wondering, how can I pass connection specific information (user name, password) to my PasswordNegotiationFilter when I don't even have a hold of an IoSession. (I only obtain the IoSession after the connectFuture completes. This is not good because if the connectFuture only completes after the password has been negotiated, the password negotiation data will only get initialized too late).
>>
>> Chicken and Egg Question:
>>
>> So how can I instantiate session specific information such as user name and password so it can get used in my IoFilters if I intend to intercept the connectFuture until the password has been negotiated?
>>
>> What do you think?
>>
>> Thanks for your help! :.)
>>
>> P.S.:
>> I have a vague idea of how to do it... Don't intercept the connectFuture in the password negotiation filter, initialize session specific information in the IoSession in the callback handler of the connectFuture. Have the password negotiation filter send a virtual message which will be intercepted by a ReadFuture's callback handler, and execute some logic in the ReadFuture's callback listener... What do you think?
>>
>>
>> Thanks,
>>
>> Simon
>>
>> -----Original Message-----
>> From: 이희승 (Trustin Lee) [mailto:trustin@gmail.com]
>> Sent: March-31-08 11:41 AM
>> To: users@mina.apache.org
>> Subject: Re: IoFuture and OnConnect event question
>>
>> Hi Simon,
>>
>> You already have posted an updated question, but let me answer again
>> from somewhat different aspect.
>>
>> On Tue, 2008-03-25 at 23:36 +0900, Simon Trudeau wrote:
>>> I am currently writing an application who establishes a connection
>>> with a legacy server and negotiates a custom password protection. I
>>> implemented my password protection negotiation scheme as an IoFilter
>>> since it is the server who instigates the password exchange. Since a
>>> connection is not really considered complete (for the purpose of
>>> sending ordinary messages) until the password has been negotiated, it
>>> there a way to delay the ConnectListener.operationComplete, until my
>>> password negotiation IoFilter has run?
>> You can intercept sessionCreated (sessionOpened in 1.x) event and stop
>> propagation of sessionCreated, sessionOpened, messageReceived and
>> store the all the intercepted events to some data structure such as queue.
>> When a client is authenticated, you can call nextFilter.<event>()
>> method for all previously intercepted and queued events to continue
>> the connection. ConnectFuture will not be triggered until
>> sessionCreated (sessionOpened in 1.x) event is propagated to
>> IoHandler, so this should work as you expected.
>>
>>> More generally, when are the IoFutureListener invoked? Before or
>>> after the IoFilters?
>> ConnectFuture notifies its listeners right after
>> IoHandler.sessionCreated() (sessionOpened in 1.x) is invoked.
>>
>> Other futures such as WriteFuture and CloseFuture notify the
>> completion of operation immediately. I can be invoked both before and
>> after the IoFilters - they are independent from each other.
>>
>>> I guess I could intercept in my Password Negotiation IoFilter the
>>> sessionOpened event until the right password has been sent and
>>> accepted by the server, after which I could let the sessionOpened
>>> propagate up to the IoHandler...
>>>
>>> What do you think?
>> Yes, you can do that as I mentioned. You might want to take a look
>> into the SslFilter.java because it does something similar.
>>
>
> --
> Trustin Lee - Principal Software Engineer, JBoss, Red Hat
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
>
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: IoFuture and OnConnect event question
Posted by 이희승 (Trustin Lee) <t...@gmail.com>.
Hi Simon,
There's a filter called IoSessionAttributeInitializingFilter. You can
insert that filter at the first place of the filter chain to add some
attributes before events hit your filters.
HTH,
Simon Trudeau wrote:
> Thanks for the info, it looks very promising.
>
> I would really like to delay the invocation of the sessionCreated after the password has been negotiated. Unfortunately, I use the IoFutureListener to be notified of when an IoSession gets created to set the credentials that are needed for the password negotiation. So I was wondering, how can I pass connection specific information (user name, password) to my PasswordNegotiationFilter when I don't even have a hold of an IoSession. (I only obtain the IoSession after the connectFuture completes. This is not good because if the connectFuture only completes after the password has been negotiated, the password negotiation data will only get initialized too late).
>
> Chicken and Egg Question:
>
> So how can I instantiate session specific information such as user name and password so it can get used in my IoFilters if I intend to intercept the connectFuture until the password has been negotiated?
>
> What do you think?
>
> Thanks for your help! :.)
>
> P.S.:
> I have a vague idea of how to do it... Don't intercept the connectFuture in the password negotiation filter, initialize session specific information in the IoSession in the callback handler of the connectFuture. Have the password negotiation filter send a virtual message which will be intercepted by a ReadFuture's callback handler, and execute some logic in the ReadFuture's callback listener... What do you think?
>
>
> Thanks,
>
> Simon
>
> -----Original Message-----
> From: 이희승 (Trustin Lee) [mailto:trustin@gmail.com]
> Sent: March-31-08 11:41 AM
> To: users@mina.apache.org
> Subject: Re: IoFuture and OnConnect event question
>
> Hi Simon,
>
> You already have posted an updated question, but let me answer again
> from somewhat different aspect.
>
> On Tue, 2008-03-25 at 23:36 +0900, Simon Trudeau wrote:
>> I am currently writing an application who establishes a connection with
>> a legacy server and negotiates a custom password protection. I
>> implemented my password protection negotiation scheme as an IoFilter
>> since it is the server who instigates the password exchange. Since a
>> connection is not really considered complete (for the purpose of sending
>> ordinary messages) until the password has been negotiated, it there a
>> way to delay the ConnectListener.operationComplete, until my password
>> negotiation IoFilter has run?
>
> You can intercept sessionCreated (sessionOpened in 1.x) event and stop
> propagation of sessionCreated, sessionOpened, messageReceived and store
> the all the intercepted events to some data structure such as queue.
> When a client is authenticated, you can call nextFilter.<event>() method
> for all previously intercepted and queued events to continue the
> connection. ConnectFuture will not be triggered until sessionCreated
> (sessionOpened in 1.x) event is propagated to IoHandler, so this should
> work as you expected.
>
>> More generally, when are the IoFutureListener invoked? Before or after
>> the IoFilters?
>
> ConnectFuture notifies its listeners right after
> IoHandler.sessionCreated() (sessionOpened in 1.x) is invoked.
>
> Other futures such as WriteFuture and CloseFuture notify the completion
> of operation immediately. I can be invoked both before and after the
> IoFilters - they are independent from each other.
>
>> I guess I could intercept in my Password Negotiation IoFilter the
>> sessionOpened event until the right password has been sent and accepted
>> by the server, after which I could let the sessionOpened propagate up to
>> the IoHandler...
>>
>> What do you think?
>
> Yes, you can do that as I mentioned. You might want to take a look into
> the SslFilter.java because it does something similar.
>
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
RE: IoFuture and OnConnect event question
Posted by Simon Trudeau <st...@bluetreewireless.com>.
Thanks for the info, it looks very promising.
I would really like to delay the invocation of the sessionCreated after the password has been negotiated. Unfortunately, I use the IoFutureListener to be notified of when an IoSession gets created to set the credentials that are needed for the password negotiation. So I was wondering, how can I pass connection specific information (user name, password) to my PasswordNegotiationFilter when I don't even have a hold of an IoSession. (I only obtain the IoSession after the connectFuture completes. This is not good because if the connectFuture only completes after the password has been negotiated, the password negotiation data will only get initialized too late).
Chicken and Egg Question:
So how can I instantiate session specific information such as user name and password so it can get used in my IoFilters if I intend to intercept the connectFuture until the password has been negotiated?
What do you think?
Thanks for your help! :.)
P.S.:
I have a vague idea of how to do it... Don't intercept the connectFuture in the password negotiation filter, initialize session specific information in the IoSession in the callback handler of the connectFuture. Have the password negotiation filter send a virtual message which will be intercepted by a ReadFuture's callback handler, and execute some logic in the ReadFuture's callback listener... What do you think?
Thanks,
Simon
-----Original Message-----
From: 이희승 (Trustin Lee) [mailto:trustin@gmail.com]
Sent: March-31-08 11:41 AM
To: users@mina.apache.org
Subject: Re: IoFuture and OnConnect event question
Hi Simon,
You already have posted an updated question, but let me answer again
from somewhat different aspect.
On Tue, 2008-03-25 at 23:36 +0900, Simon Trudeau wrote:
> I am currently writing an application who establishes a connection with
> a legacy server and negotiates a custom password protection. I
> implemented my password protection negotiation scheme as an IoFilter
> since it is the server who instigates the password exchange. Since a
> connection is not really considered complete (for the purpose of sending
> ordinary messages) until the password has been negotiated, it there a
> way to delay the ConnectListener.operationComplete, until my password
> negotiation IoFilter has run?
You can intercept sessionCreated (sessionOpened in 1.x) event and stop
propagation of sessionCreated, sessionOpened, messageReceived and store
the all the intercepted events to some data structure such as queue.
When a client is authenticated, you can call nextFilter.<event>() method
for all previously intercepted and queued events to continue the
connection. ConnectFuture will not be triggered until sessionCreated
(sessionOpened in 1.x) event is propagated to IoHandler, so this should
work as you expected.
> More generally, when are the IoFutureListener invoked? Before or after
> the IoFilters?
ConnectFuture notifies its listeners right after
IoHandler.sessionCreated() (sessionOpened in 1.x) is invoked.
Other futures such as WriteFuture and CloseFuture notify the completion
of operation immediately. I can be invoked both before and after the
IoFilters - they are independent from each other.
> I guess I could intercept in my Password Negotiation IoFilter the
> sessionOpened event until the right password has been sent and accepted
> by the server, after which I could let the sessionOpened propagate up to
> the IoHandler...
>
> What do you think?
Yes, you can do that as I mentioned. You might want to take a look into
the SslFilter.java because it does something similar.
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: IoFuture and OnConnect event question
Posted by "이희승 (Trustin Lee)" <tr...@gmail.com>.
Hi Simon,
You already have posted an updated question, but let me answer again
from somewhat different aspect.
On Tue, 2008-03-25 at 23:36 +0900, Simon Trudeau wrote:
> I am currently writing an application who establishes a connection with
> a legacy server and negotiates a custom password protection. I
> implemented my password protection negotiation scheme as an IoFilter
> since it is the server who instigates the password exchange. Since a
> connection is not really considered complete (for the purpose of sending
> ordinary messages) until the password has been negotiated, it there a
> way to delay the ConnectListener.operationComplete, until my password
> negotiation IoFilter has run?
You can intercept sessionCreated (sessionOpened in 1.x) event and stop
propagation of sessionCreated, sessionOpened, messageReceived and store
the all the intercepted events to some data structure such as queue.
When a client is authenticated, you can call nextFilter.<event>() method
for all previously intercepted and queued events to continue the
connection. ConnectFuture will not be triggered until sessionCreated
(sessionOpened in 1.x) event is propagated to IoHandler, so this should
work as you expected.
> More generally, when are the IoFutureListener invoked? Before or after
> the IoFilters?
ConnectFuture notifies its listeners right after
IoHandler.sessionCreated() (sessionOpened in 1.x) is invoked.
Other futures such as WriteFuture and CloseFuture notify the completion
of operation immediately. I can be invoked both before and after the
IoFilters - they are independent from each other.
> I guess I could intercept in my Password Negotiation IoFilter the
> sessionOpened event until the right password has been sent and accepted
> by the server, after which I could let the sessionOpened propagate up to
> the IoHandler...
>
> What do you think?
Yes, you can do that as I mentioned. You might want to take a look into
the SslFilter.java because it does something similar.
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/