[MINA] and readiness selection.

[Bharath Sundararaman <Bh...@starthis.com>]

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 :-)

 

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:

1.	SocketAcceptor listens on port X; SocketAcceptor connects and
specifies a handler (let's say ClientHandler)
2.	SocketConnector gets the "IoSession" object returned by the
"connect(address,handler)" method and does a
session.write(buffer,marker); where buffer contains "hello".
3.	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);
4.	This triggers the dataRead() method in the SocketConnector's
handler which prints out the modified buffer.

 

My questions:

1.	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?
2.	It seems that the IoSession object, when changed, is what
notifies the server or the SocketAcceptor that a
client/channel/socketconnector is ready. 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?
3.	What is the DemuxingProtocolHandler? Do I need it for readiness
selection?
4.	what is the real gain with using MINA for this process?

 

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

 

________________________________

From: Brad Baker [mailto:bbakerman@gmail.com] 
Sent: Thursday, June 09, 2005 1:16 AM
To: dev@directory.apache.org
Subject: [mina] How to delay reading and writing when using Mina

 

I have only just begun to examine the Mina code base and was hoping
someone could validate the following assumptions for me.  What follows
is a mini design followed by my assumptions.

Mini Design :
=============

* What I want to acheive is a "MINA process" that accepts incoming
client connections, and then "buffers" them ready for a completely
separate process (eg outside the VM) which will ask for "any incoming
requests".  The processing of requests and replies would be done in a
asynch manner.

* For the record this "separate process" is a commercial message broker
that talks other protocols but doesnt do native TCPIP sockets.  Hence
the separation of TCPIP handling and the cross process communication.

* The "MINA process" would accept client requests without reading them
or replying to them (timeout handling is assumed here of course) .
Rather the "MINA process" would "put the "ProtocolSession" aside in a
memory table ready for later "reading and processing". (This might be
tweaked to read the request first but certainly not write a reply then
and there)

* The "outside process" would ask for "work" from ther MINA process at
its leisure, at which time the "MINA process" would "read" the data from
the "stored ProtocolSession" and pass that over to the "outside
process".  

* Once the "outside process" had finished working on the "data" it would
"pass a reply back" to the "MINA process" and have the MINA process
"write" the reply data down the "stored" ProtocolSession.


Assumptions:
=============

* The ProtocolSession objects can be "stored" for later use and do not
have to read from nor written to immediately.  Rather they can be "set
aside" and read from at some later asynch event (inside a timeout
periods of course)

*  The use of 2 ThreadPoolFilters (the IO one and the Protocol one) will
enabled a level of "asynchronisity" to allow for "asynch" servicing of
requests.

* The "MINA" process can "listen" on more than 1 port at a time (one for
client request communication and one for "MINA process to outside
process" communication)

* Arbitary "periods" can occur between accepting/reading and writing to
the Session objects.

Second Mini Design 
================

* The MINA process could do the same sort thing as above but acting as a
client instead of a server.  eg the "outside prcocess" could ask for a
client connection to be made to some other system.  The MINA process
would "call out" as a client and then "store" the outbound Session
somewhere.

* Multiple outbound "client calls" could be made with one or more
"selector" threads looking for potential replies, never waiting long for
any given reply.  if it gets a reply message, it would read the data and
store it.

* The "outside process" would periodically ask for "replies" (using a
magic key assigned earlier) in which case any replies found with that
key would be returned.


Assumptions:
=============

* MINA can do client style connections as well as server style
connections

* MINA code can have multiple outstanding "client connections" with a
"selector" thread that can "tell" when they have become readable?

* Multiple SocketConnectors would be the way to do this?

Cheers
Brad Baker

Re: [MINA] and readiness selection.

[Vinod Panicker <vi...@gmail.com>]

On 6/9/05, Bharath Sundararaman <Bh...@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.