mina-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache MINA > MINA 3.0 design
Date Wed, 15 Jul 2009 14:58:00 GMT
<html>
<head>
    <base href="http://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/1519/1/1/_/styles/combined.css?spaceKey=MINA&amp;forWysiwyg=true"
type="text/css">
    </head>
<body style="background-color: white" bgcolor="white">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
     <h2><a href="http://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design">MINA
3.0 design</a></h2>
     <h4>Page <b>edited</b> by             <a href="http://cwiki.apache.org/confluence/display/~elecharny">Emmanuel
Lécharny</a>
    </h4>
     Added some features about SSLFiltering
          <div id="versionComment" class="noteMacro" style="display:none; padding: 5px;">
     Added some features about SSLFiltering<br />
     </div>
          <br/>
     <div class="notificationGreySide">
         
<style  TYPE="text/css">
    .ele
    {
        padding-left:10px;
        border-left: 2px solid;
        border-color: green;
        background-color: #DDFFBB;
    }
    .ede
    {
        padding-left:10px;
        border-left: 2px solid;
        border-color: #7500EA;
        background-color: #BCBBFF;
    }
    .vrm
    {
        padding-left:10px;
        border-left: 2px solid;
        border-color: red;
        background-color: #FFCCBB;
    }
</style>


<div class='panelMacro'><table class='warningMacro'><colgroup><col width='24'><col></colgroup><tr><td
valign='top'><img src="/confluence/images/icons/emoticons/forbidden.gif" width="16"
height="16" align="absmiddle" alt="" border="0"></td><td><p>Due to the
way Confluence modifies the pages when it opens it in the RichText editor, the presentation
is totally screwed up when saving in this mode.</p>

<p>Until we find a way to keep the cool HTML presentation we currently have, please
<b>don't</b> save this page if you have edited it on Rich Text format. Try to
edit it in Wiki Markup instead.</p>

<p>Thanks !</p></td></tr></table></div>

<h1><a name="MINA3.0design-Introduction"></a>Introduction</h1>

<p>This page is intended to be a place open for discussion about MINA 3.0 features.
Comments and ideas are very welcome !</p>

<h1><a name="MINA3.0design-Mina3.0designandexpectedfeatures"></a>Mina 3.0
design and expected features</h1>

<p>Some thoughts about what I see important to have in MINA 3.0...</p>


<h2><a name="MINA3.0design-selectorsusage"></a>selectors usage </h2>
<p>We should be able to define the number of selectors to use, and to define what they
will be used for. For instance, atm, we have a selector in the Acceptor, plus a selector per
Processor. This is not necessarily the best solution.</p>

<ul>
	<li>do some perf tests to see if it's better to use one or many selectors.</li>
	<li>decouple the selector usage from the the selector definition. It should be possible
to define one single selector and use it in many places</li>
	<li>the Acceptor and Processor should not necessarily be associated with a thread.
it's up to the user to define the thread model to use
<div class="vrm"><strong>vrm :</strong>
Actually look like we need different strategy for different usage. 
On the right threading/selector strategy look like there is no real
consensus and we will need to experiment for finding the default
solution.
</div></li>
</ul>


<h2><a name="MINA3.0design-Chain"></a>Chain</h2>
<p>The current chain implemention is cumbersome. We would like to have something easier
to manipulate, and also easier to debug.</p>

<ul>
	<li>the chain should be optionally dynamic : a session can add a new filter in the
chain whenever needed</li>
</ul>


<ul>
	<li>we should not always copy the chain in each session, if the chain is immutable
<div class="vrm"><strong>vrm :</strong>
Yes, cause most of time we configure the chain on the acceptor and never change it again.
Look like we agreed on copy-on-write for that.
</div></li>
</ul>


<ul>
	<li>however, it should be possible to change the global chain without breaking the
processing.
<div class="ede"><strong>ede :</strong> Tricky : will this affect only new
sessions or started sessions too ? </div>
<div class="ele"><strong>ele :</strong> All the sessions. I don't see a
clear and easy to implement mechanism to protect the current sessions from such a change.
Npw, as the chain is just a structure used to keep a list of filter to go through, it should
be easy to guarantee that a session requesting the next filter is not affected by the change.
</div></li>
</ul>


<ul>
	<li>we should have one chain for incoming messages, and another one for outgoing messages</li>
</ul>


<ul>
	<li>it should be possible to have a multi-stage codec (ie, add more than one codec
filter in the chain)
<div class="vrm"><strong>vrm :</strong>
Mandatory, it's very often I use a TextLineCodec and a String-to-Pojo filter, and I'm sure
I'm not alone.
</div></li>
</ul>


<ul>
	<li>we should allow a queuing mechanism to be put in between each filters
<div class="vrm"><strong>vrm :</strong>
What is that for ? Look like you got a new idea  :) 
</div>
<div class="ele"><strong>ele :</strong>
Nothing new there : it's just to allow SEDA implementation.
</div></li>
</ul>


<ul>
	<li>the Head and Tail filters are useless : they should be removed
<div class="vrm"><strong>vrm :</strong>
Yes
</div>
<div class="ede"><strong>ede :</strong> These are just implementation details
of the actual chain</div></li>
</ul>



<ul>
	<li>a chain may not be a list of filters. It can be a graph
<div class="vrm"><strong>vrm :</strong>
If we can keep the API simple enough, why not.
</div>
<div class="ede"><strong>ede :</strong> This imho will greatly increase
the complexity of the chain ( cycle detection mechanism ?) </div>
<div class="ele"><strong>ele :</strong>Yes, this is probably not the most
simple thing to implement ...</div></li>
</ul>


<h2><a name="MINA3.0design-Filters"></a>Filters</h2>

<ul>
	<li>a filter should accept a stream&lt;Object&gt;, the Object can change from
one filter to another. it's up to the user to correctly handle the Object.
<div class="vrm"><strong>vrm :</strong>
You want to say multi layer codec ?
</div>
<div class="ele"><strong>ele :</strong>
That's a part of it. 
</div></li>
</ul>


<ul>
	<li>the executor filter could be present in more than one place in the chain (SEDA)
<div class="vrm"><strong>vrm :</strong>
Mandatory if someone really want SEDA.
</div>
<div class="ele"><strong>ele :</strong>
Plus we need to have queues in the middle. Maybe we should call it SedaFilter instead...
</div></li>
</ul>


<ul>
	<li>statistic must be established with a filter
<div class="vrm"><strong>vrm :</strong>
Again mandatory. You won't do stats the same way on HTTP or FTP and stats can be very costy.
</div>
<div class="ede"><strong>ede :</strong> Moreover they actually are not accurate
and only darken the code ... </div></li>
</ul>


<ul>
	<li>we should define two interfaces for filters : IngoingFilter and OutgoingFilter.
They will expose the methods to process ingoing and outgoing messages
<div class="vrm"><strong>vrm :</strong>
The question is where to put sessionOpen/Closed/Idle in a two chains model.
</div>
<div class="ele"><strong>ele :</strong>
As the session is managed at the upper level, such messages must be propagated from the processor
to the handler, not the way around.
</div>
<div class="ede"><strong>ede :</strong> So sessionOpen/Closed/Idle should
be added to IncomingFilter. What about ExceptionCaught event ?</div>
<div class="ele"><strong>ele :</strong> ExceptionCaught event are not supposed
to be incoming event, AFAIK...</div></li>
</ul>


<ul>
	<li>The SSL filter should not be a filter at all: it's a part of the underlying protocol,
and the handshake should be done previously to any kind of exchange. Another option would
be to move this filter in the first position in the chain.</li>
</ul>


<h2><a name="MINA3.0design-Session"></a>Session </h2>

<ul>
	<li>we should have two kind of sessions : stateful and stateless. Sometime, we don't
need to store any kind of information in a session
<div class="vrm"><strong>vrm :</strong>
If we create the HashMap on first additon, where is the gain ?
</div>
<div class="ele"><strong>ele :</strong>
If a session is stateful, not creating a structure to store data which won't be added will
eat less memory. We can create this container only when necessary, obviously when the session
is created, but then if we have two kind of session classes, we will immediately know when
to create this container. 
</div></li>
</ul>


<ul>
	<li>we should add a sessionManager instead of all the existing queues used to manage
the dead sessions, the idle sessions, etc.
<div class="vrm"><strong>vrm :</strong>
We need to rethink the whole separation between IoProcessor and IoService and where we manage
closing/accepting queues.
</div></li>
</ul>


<ul>
	<li>session should not necessarily be associated with a processor.
<div class="vrm"><strong>vrm :</strong>
+1
</div></li>
</ul>


<ul>
	<li>If a session is stateful, then we should attach the data to the channel instead
of creating a map for that
<div class="vrm"><strong>vrm :</strong>
Can you say more about that, where is the gain ?
</div>
<div class="ele"><strong>ele :</strong>
Simplicity : no need to define a container which already exists, as you can attach Objects
to the SelectionKey.
Jean-François Arcand has blogged about how dangerous it is : http://weblogs.java.net/blog/jfarcand/archive/2006/06/tricks_and_tips.html,
but this is dangerous *if* one code its own server without dealing with session expiration.
As we are defining a framework, this is not a problem for us.
</div></li>
</ul>


<ul>
	<li>A session must be attached to an acceptor, allowing more than one chain if the
acceptor is to deal with more than one single SocketServer
<div class="vrm"><strong>vrm :</strong>
We need to find away for running more than 1 kind of port/protocol with
the same set of Thread/Executors. I suppose it would be interesting
for ADS. On my side I run servers with 3 or 4 SocketAcceptors for
different protocols, somthing like 10 SocketConnectors for different
protocols.
Perfs aren't an issue for me actually, but it can change.
</div>
<div class="ele"><strong>ele :</strong>
ADS deal with LDAP, DNS, Kerberos, Ntp, Dhcp. Atm, we create one NioAcceptor per protocol,
a bit overkilling (not to mention that we have as many NioProcessors...
</div></li>
</ul>


<div class="ele"><strong>ele :</strong>
Moreover, I think that the name we are using is incorrect. An acceptor or a connector are
not services, but transports. They just take care of incoming connections, sessions creation
and data transfert. The real service is the implemented protocol, which is handler by the
session's chain, all the filters and the handler. If we also combine the configuration with
the service, we are golden.

MINA 3.0 must reflect this. 
</div>

<ul>
	<li>It should be possible to close a session on a specific message reception, without
having to add a listener for that
<div class="ede"><strong>ede :</strong> use case ? </div>
<div class="ele"><strong>ele :</strong>Atm, if one want to close a session
in a filter (black list) or in the handler, it's a bit tricky, as a listener must be added
in order to close the session. This mechanism is cumbersome</div></li>
</ul>


<h2><a name="MINA3.0design-codec"></a>codec</h2>
<ul>
	<li>we don't have stateful or stateless codecs. We should distinguish the two kinds
of codec someone can use.
<div class="vrm"><strong>vrm :</strong>
+1
</div></li>
	<li>we should define a collection of existing codecs
<div class="vrm"><strong>vrm :</strong>
For that we need a standard way of doing a codec on the Pojo side. I'm sure LDAP pojo for
ADs are very different (and got different dependencies) of the one of Asyncweb or Vysper.
</div>
<div class="ele"><strong>ele :</strong>
They are very different. The codec should define not only the encoder and the decoder, but
the associated POJOs.
</div></li>
	<li>as we can handle more than one protocol, we must add a demuxingCodec which point
to the next filter, conditionally
<div class="vrm"><strong>vrm :</strong>
Here the graph ?  :) 
</div>
<div class="ele"><strong>ele :</strong>
Yes
</div></li>
</ul>



<h2><a name="MINA3.0design-Buffer"></a>Buffer</h2>
<ul>
	<li>We should not wrap ByteBuffer into our own IoBuffer class. We should have a list
of ByteBuffers instead, containing all the ByteBuffers.
<div class="vrm"><strong>vrm :</strong>
And some extended Stream interface for manipulation.
</div></li>
	<li>The chain API should be modified to expose Streams of generic types (Stream&lt;K&gt;)
instead of IoBuffer, allowing us to add more than one codec filter in the chain (each Filter
being aware of the kind of Object it can manipulate)</li>
</ul>


<h2><a name="MINA3.0design-General"></a>General</h2>
<ul>
	<li>offer a NIO 2.0 library
<div class="vrm"><strong>vrm :</strong>
Well it's going to be soon mandatory  :) 
</div></li>
	<li>Use real Future implementation</li>
	<li>Support Multicast</li>
	<li>Create a benchmark suite</li>
</ul>



<p>This is just a starting point ...</p>
<div class="vrm"><strong>vrm :</strong>
We need at first a great test platform for testing the different
protocols and implementation ideas (Thread/Selector/Channel
strategies). So we make choice based on facts for the engine.
</div>
     </div>
     <div id="commentsSection" class="wiki-content pageSection">
       <div style="float: right;">
            <a href="http://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
       </div>

       <a href="http://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design">View
Online</a>
       |
       <a href="http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120101&revisedVersion=12&originalVersion=11">View
Change</a>
              |
       <a href="http://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

Mime
View raw message