|
Home > Archive > Apache Directory Project > December 2005 > [MINA] Using MINA to write a proxy server like application
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[MINA] Using MINA to write a proxy server like application
|
|
| Srikanth Veeramachaneni 2005-12-01, 8:45 pm |
| Hello,
I have an existing proxy-like server which currently uses blocking IO.
The role of the proxy server is to communicate with the client using SSL
and act as a proxy to the application server communicating with it using
plain TCP.
TCP/SSL TCP
Client -----------------> Proxy Server -----------> Application Server
The protocol being supported is a stateful synchronous command/response
protocol where the client initiates all the communication by sending
commands and the server responds by sending responses. The only exception
is that at the time of connection establishment the server sends a
greeting back to the client.
The normal process flow for the proxy would be something like below
1. Client initiates SSL connection
2. Proxy accepts connection and starts SSL handshake
3. After SSL handshake is successfully completed, proxy establishes
connection to the application server
4. Read greeting from application server
5. Send greeting to client
6. Read command from client
7. Send command to application server
8. Read response from application server
9. Send response to client
10. Repeat steps 6 through 9
I am trying to see if I can use MINA to support the proxy server
and am in the process of building a prototype.
I basically took the EchoServer example and started modifying it to serve
my needs. I also made modifications to the SSLHandler class so that
sessionOpened() will be invoked a second time once the SSL handshake is
complete (as suggested by Maarten Bosteels).
At this point, in the sessionOpened() method, I am opening a session to
the application server using SocketConnector. I then set the source client
session as an attachment in the destination app server session and the
destination app server session as an attachment in the source client
session, so that the source client session and the destination app server
session can pipe data to each other in the dataRead() methods.
This approach works but the problem I am facing is that sometimes the
greeting from the APP server is being read even before the source client
session is set as an attachment to the destination app server session. The
source client session is absolutely needed here as I need to write the
greeting to it.
In order to get around this problem I made the dataRead() method of the
destination session handler wait in a loop until the source client session
becomes visible and then only it proceeds to write the greeting to the Clie=
nt.
Finally my questions
- I consider my above solution to the greeting problem a very bad hack.
What is the best approach to handle such a need?
- Is my approach overall reasonable? i.e. opening a session to
the application server once the SSL handshake is completed and then
piping the read event to each other in the dataRead() methods of each
of these sessions and using the attachments to enable the data piping.
- Are there better approaches or alternatives?
I am quite new to MINA and NIO in general. So, please feel free to point ou=
t
if I am totally being inefficient here.
Attached are the relevant classes from my prototype.
thanks,
Srikanth
| |
| Srikanth Veeramachaneni 2005-12-01, 8:45 pm |
| Ooops! Forgot to attach the files.
On 12/1/05, Srikanth Veeramachaneni <sveerama-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hello,
>
> I have an existing proxy-like server which currently uses blocking IO.
> The role of the proxy server is to communicate with the client using SSL
> and act as a proxy to the application server communicating with it using
> plain TCP.
>
> TCP/SSL TCP
> Client -----------------> Proxy Server -----------> Application Server
>
>
> The protocol being supported is a stateful synchronous command/response
> protocol where the client initiates all the communication by sending
> commands and the server responds by sending responses. The only exception
> is that at the time of connection establishment the server sends a
> greeting back to the client.
>
> The normal process flow for the proxy would be something like below
>
> 1. Client initiates SSL connection
> 2. Proxy accepts connection and starts SSL handshake
> 3. After SSL handshake is successfully completed, proxy establishes
> connection to the application server
> 4. Read greeting from application server
> 5. Send greeting to client
> 6. Read command from client
> 7. Send command to application server
> 8. Read response from application server
> 9. Send response to client
> 10. Repeat steps 6 through 9
>
> I am trying to see if I can use MINA to support the proxy server
> and am in the process of building a prototype.
>
> I basically took the EchoServer example and started modifying it to serve
> my needs. I also made modifications to the SSLHandler class so that
> sessionOpened() will be invoked a second time once the SSL handshake is
> complete (as suggested by Maarten Bosteels).
>
> At this point, in the sessionOpened() method, I am opening a session to
> the application server using SocketConnector. I then set the source client
> session as an attachment in the destination app server session and the
> destination app server session as an attachment in the source client
> session, so that the source client session and the destination app server
> session can pipe data to each other in the dataRead() methods.
>
> This approach works but the problem I am facing is that sometimes the
> greeting from the APP server is being read even before the source client
> session is set as an attachment to the destination app server session. The
> source client session is absolutely needed here as I need to write the
> greeting to it.
>
> In order to get around this problem I made the dataRead() method of the
> destination session handler wait in a loop until the source client session
> becomes visible and then only it proceeds to write the greeting to the Client.
>
> Finally my questions
>
> - I consider my above solution to the greeting problem a very bad hack.
> What is the best approach to handle such a need?
> - Is my approach overall reasonable? i.e. opening a session to
> the application server once the SSL handshake is completed and then
> piping the read event to each other in the dataRead() methods of each
> of these sessions and using the attachments to enable the data piping.
> - Are there better approaches or alternatives?
>
> I am quite new to MINA and NIO in general. So, please feel free to point out
> if I am totally being inefficient here.
>
> Attached are the relevant classes from my prototype.
>
> thanks,
> Srikanth
>
| |
| Trustin Lee 2005-12-01, 8:45 pm |
| Hi Srikanth,
2005/12/2, Srikanth Veeramachaneni <sveerama-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
> - I consider my above solution to the greeting problem a very bad hack.
> What is the best approach to handle such a need?
You can create a queue that buffers the data until the attachment is set.
You notify the handler when after you set the attachment, then the queue has
to be flushed. WDYT? This is actually the technique I'm using in
SSLFilter.
- Is my approach overall reasonable? i.e. opening a session to
> the application server once the SSL handshake is completed and then
> piping the read event to each other in the dataRead() methods of each
> of these sessions and using the attachments to enable the data piping.
It's absolutely OK. 
- Are there better approaches or alternatives?
What you're doing is what most others are doing to implement a proxy server
in MINA. It's good.
I am quite new to MINA and NIO in general. So, please feel free to point out
> if I am totally being inefficient here.
You're doing fine. Please let us know any difficulties you suffered from
MINA. We're completely open to user feed back! 
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
| |
| Maarten Bosteels 2005-12-02, 7:45 am |
| Srikanth Veeramachaneni wrote:
>The protocol being supported is a stateful synchronous command/response
>protocol where the client initiates all the communication by sending
>commands and the server responds by sending responses. The only exception
>is that at the time of connection establishment the server sends a
>greeting back to the client.
>
>The normal process flow for the proxy would be something like below
>
> 1. Client initiates SSL connection
> 2. Proxy accepts connection and starts SSL handshake
> 3. After SSL handshake is successfully completed, proxy establishes
> connection to the application server
> 4. Read greeting from application server
> 5. Send greeting to client
> 6. Read command from client
> 7. Send command to application server
> 8. Read response from application server
> 9. Send response to client
> 10. Repeat steps 6 through 9
>
Hi Srikanth,
Sounds a lot like the Extensible Provisioning Protocol (EPP) or is this
just coincidence ?
http://www.faqs.org/rfcs/rfc3730.html
Maarten
| |
|
|
|
|
|