directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Panicker <>
Subject Re: [MINA] and readiness selection.
Date Fri, 10 Jun 2005 04:45:45 GMT
On 6/9/05, Bharath Sundararaman <> 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 )>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

> 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

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


View raw message