directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bharath Sundararaman" <Bharath.Sundarara...@starthis.com>
Subject RE: [MINA] and readiness selection.
Date Fri, 10 Jun 2005 15:33:30 GMT

Hi Vinod,

>>> MINA provides thread pools that you can use to achieve better 
concurrency.
Are there any examples that use thread pools? 

Thanks a bunch for your reply. 

-----Original Message-----
From: Vinod Panicker [mailto:vinod.p@gmail.com] 
Sent: Thursday, June 09, 2005 11:46 PM
To: Apache Directory Developers List
Subject: Re: [MINA] and readiness selection.

On 6/9/05, Bharath Sundararaman <Bharath.Sundararaman@starthis.com>
wrote:
> 
> Hi all, 
> 
> I tried to use MINA to implement the readiness selection process where
> multiple clients/channels register with a selector for an event of
interest,
> which when fired will cause the selector to dispatch it to a handler.
I
> would like to confirm that I'm using MINA the right way to achieve
this and
> also know what advantages MINA provides me, apart from lesser lines of
code
> J 
> 
> Objective: The server listens on a port; client connects to it and
writes
> some data (an input string, let's say, "hello") into its own buffer.
Client
> wants the server to now read its buffer ("hello") and write back
> "hellohello" into its buffer. Basically duplicate and append to the
end. 
> 
> When using NIO, I would first register SelectionKey.OP_ACCEPT with the
> server and then check for any ready keys (is Selector.select( )>0). If
so, I
> check for key.isReadable() method and if the key is readable, I get
the
> socket channel, read its buffer ("hello"), create a new buffer
> ("hellohello") and write it back. 
> 
> MINA: 
>  
> SocketAcceptor listens on port X; SocketAcceptor connects and
specifies a
> handler (let's say ClientHandler) 

In usual cases, this would be called "ServerHandler"

> SocketConnector gets the "IoSession" object returned by the
> "connect(address,handler)" method and does a
session.write(buffer,marker);
> where buffer contains "hello". 
> This triggers the dataRead() method in the SocketAcceptor's handler
(let's
> say ServerHandler) which reads the buffer, creates a new modified
buffer and
> writes it back using session.write(buffer,marker); 
> This triggers the dataRead() method in the SocketConnector's handler
which
> prints out the modified buffer. 

The approach is basically fine.  You might want to look at the
examples in the source to get better ideas on the possibilities with
MINA.

> My questions: 
>  
> From a quick look at MINA's source code, if there is a single
SocketAcceptor
> and multiple SocketConnectors write into their buffers at the same
time (in
> other words, become "readable"), it seems that all the requests are
> immediately received, pushed into a registration queue and processed
one by
> one, to enable non-blocking I/O. I do the same thing while using
java.nio
> classes. Is MINA better in handling large number of clients which
become
> ready at the same time and require the server's attention, due to some
> reason? How does it enhance my readiness selection process? 

MINA provides thread pools that you can use to achieve better
concurrency.  Basically you already have the headache of accepting
connections and processing them taken care of.

> It seems that the IoSession object, when changed, is what notifies the
> server or the SocketAcceptor that a client/channel/socketconnector is
ready.

Umm.. no.  This notification process is basically NIO doing its job.

> Does the SocketAcceptor periodically check if the session object has
> changed? Does the session object notify the SocketAcceptor by invoking
some
> method as soon as it changes? How does this tie up work? 

As mentioned before, this is NIO functionality.  The SocketAcceptor is
registering for the OP_ACCEPT event, and later the OP_ACCEPT event
once the connection is accepted.  Due to this it gets notifications
from the NIO layer.

> What is the DemuxingProtocolHandler? Do I need it for readiness
selection? 

You would require the DemuxingProtocolHandler to "demultiplex" the
protocol messages that are coming to you to different MessageHandlers.
 Eg - if you are implementing the HTTP protocol, you might have a GET
handler and a POST handler.  You might opt to pass the protocol
messages that have arrived to the appropriate handlers in the
DemuxingProtocolHandler.

> what is the real gain with using MINA for this process? 

Well, you just mentioned it yourself - 

> I find MINA much more easy to use than traditional NIO, readable and
> manageable. Thanks to Trustin Lee for his efforts. 
> 
--snip--

Regards,
Vinod.

Mime
View raw message