Author: buildbot
Date: Tue Oct 25 15:58:11 2016
New Revision: 999908
Log:
Staging update by buildbot for mina
Modified:
websites/staging/mina/trunk/content/ (props changed)
websites/staging/mina/trunk/content/mina-project/userguide/ch1-getting-started/why-mina.html
Propchange: websites/staging/mina/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Tue Oct 25 15:58:11 2016
@@ -1 +1 @@
-1762605
+1766550
Modified:
websites/staging/mina/trunk/content/mina-project/userguide/ch1-getting-started/why-mina.html
==============================================================================
---
websites/staging/mina/trunk/content/mina-project/userguide/ch1-getting-started/why-mina.html
(original)
+++
websites/staging/mina/trunk/content/mina-project/userguide/ch1-getting-started/why-mina.html
Tue Oct 25 15:58:11 2016
@@ -182,32 +182,32 @@ h2:hover > .headerlink, h3:hover > .head
}
h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink,
h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink,
dt:hover > .elementid-permalink { visibility: visible }</style>
<h1 id="why-mina">Why MINA ?<a class="headerlink" href="#why-mina"
title="Permanent link">¶</a></h1>
-<p>Writing some network application is generrally seen as a burden, and a low
level development. It's a area which is not frequently studied or known by
developpers, either because it has ben studied in school a long time ago and
everything has been forgotten, or because the complexity of this network layer
is frequently hidden by higher level layers, so you never get deep into it.</p>
-<p>Add that when it comes to asynchronous IO, an extra layer of complexity
comes into play : time.</p>
-<p>The big difference between <strong>BIO</strong> (Blocking IO) and
<strong>NIO</strong> (Non-Blocking IO) is that in <strong>BIO</strong>, you
send a request, and you wait until you get the response. On the server side, it
means one thread wil be associated with any incoming connection, so you won't
have to deal with the complexity of multiplexing the connections. In
<strong>NIO</strong>, on the other hand, you have to deal with the synchronous
nature of a non-blocking system, wich means that your application will be
invoked when some events occur. In <strong>NIO</strong>, you don't call and
wait for a result, you send a command and you are informed when the result is
ready.</p>
+<p>Writing network applications are generally seen as a burden and perceived
as low level development. It is an area which is not frequently studied or
known by developers, either because it has been studied in school a long time
ago and everything has been forgotten, or because the complexity of the network
layer is frequently hidden by higher level layers, so you never get deep into
it.</p>
+<p>Added to that (when it comes to asynchronous IO) an extra layer of
complexity comes into play: time.</p>
+<p>The big difference between <strong>BIO</strong> (Blocking IO) and
<strong>NIO</strong> (Non-Blocking IO) is that in <strong>BIO</strong>, you
send a request, and you wait until you get the response. On the server side, it
means one thread wil be associated with any incoming connection, so you won't
have to deal with the complexity of multiplexing the connections. In
<strong>NIO</strong>, on the other hand, you have to deal with the synchronous
nature of a non-blocking system, which means that your application will be
invoked when some events occur. In <strong>NIO</strong>, you don't call and
wait for a result, you send a command and you are informed when the result is
ready.</p>
<h2 id="the-need-of-a-framework">The need of a framework<a class="headerlink"
href="#the-need-of-a-framework" title="Permanent link">¶</a></h2>
-<p>Considering those differences, and teh fact that most of the applications
are usually expecting a blocking mode when invoking the network layer, the best
solution is to hide this aspect by writing a framework that mimic a blocking
mode. This is what <strong>MINA</strong> does !</p>
-<p>But <strong>MINA</strong> does more. It provides a common IO vision to an
application that needs to communicate over <strong>TCP</strong>,
<strong>UDP</strong> or whatever mechanism. If we consider only
<strong>TCP</strong> and <strong>UDP</strong>, one is a connected protocol
(<strong>TCP</strong>) when the other one is connectionless
(<strong>UDP</strong>). <strong>MINA</strong> masks this difference, and make
you focus on the two parts that are important for your application : the
applicive code and the application protocol encoding/decoding.</p>
-<p><strong>MINA</strong> does not only handles <strong>TCP</strong> and
<strong>UDP</strong>, it's also offering a layer on top of serial communication
(<strong>RSC232</strong>), over <strong>VmpPipe</strong> or
<strong>APR</strong>. </p>
-<p>Last, not least, <strong>MINA</strong> is a network framework that has been
specifically designed to work either on the client side and on teh server side.
Writing a server make it critical to have a scalable system, which is tunnable
to fit the server needs, in term of performance and memory usage : this is what
<strong>MINA</strong> is good for, still making it easy to devlop you
server.</p>
+<p>Considering those differences, and the fact that most of the applications
are usually expecting a blocking mode when invoking the network layer, the best
solution is to hide this aspect by writing a framework that mimics a blocking
mode. This is what <strong>MINA</strong> does!</p>
+<p>But <strong>MINA</strong> does more. It provides a common IO vision to an
application that needs to communicate over <strong>TCP</strong>,
<strong>UDP</strong> or whatever mechanism. If we consider only
<strong>TCP</strong> and <strong>UDP</strong>, one is a connected protocol
(<strong>TCP</strong>) where the other is connectionless
(<strong>UDP</strong>). <strong>MINA</strong> masks this difference, and makes
you focus on the two parts that are important for your application: the
application code and the application protocol encoding/decoding.</p>
+<p><strong><em>MINA</em>* does not only handle </strong>TCP<strong> and
</strong>UDP<strong>, it also offers a layer on top of serial communication
(</strong>RSC232<strong>), over </strong>VmpPipe<strong> or </strong>APR**. </p>
+<p>Last but not least, <strong>MINA</strong> is a network framework that has
been specifically designed to work on both the client side and server side.
Writing a server makes it critical to have a scalable system, which is tunable
to fit the server needs, in terms of performance and memory usage. This is what
<strong>MINA</strong> is good for, making it easy to develop you server.</p>
<h2 id="when-to-use-mina">When to use MINA ?<a class="headerlink"
href="#when-to-use-mina" title="Permanent link">¶</a></h2>
-<p>This is a intersting question ! <strong>MINA</strong> does not expect to be
the best possible choice in any case. There are a few elements to consider when
considering using <strong>MINA</strong>. Let's list them :</p>
+<p>This is a interesting question! <strong>MINA</strong> does not expect to be
the best possible choice in all cases. There are a few elements to take into
account when considering using <strong>MINA</strong>. Let's list them:</p>
<ul>
<li>
<p>Ease of use
- When you have no special performance requirements, <strong>MINA</strong>
is probably a good choice as it allows you to dvelop a server or a client
easily, without having to deal with the various parameters and use cases to
handle when writing the same application on top of <strong>BIO</strong> or
<strong>NIO</strong>. You can probably write your server with a few tens of
lines, and there are a few pitfalls in which you are likely to fall</p>
+ When you have no special performance requirements, <strong>MINA</strong>
is probably a good choice as it allows you to develop a server or a client
easily, without having to deal with the various parameters and use cases to
handle when writing the same application on top of <strong>BIO</strong> or
<strong>NIO</strong>. You could probably write your server with only a few
lines of code, and there are less pitfalls in which you are likely to fall.</p>
</li>
<li>
<p>A high number of connected users
- <strong>BIO</strong> is definitively faster that <strong>NIO</strong>. The
difference is something like 30% in favor of <strong>BIO</strong>. This is true
for up to a few thousands of connected users, but up to a point, the
<strong>BIO</strong> approach just stop scaling : you won't e able to handle
millions of connected users using one thread per user ! <strong>NIO</strong>
can. Now, one other aspect is that the time spent in the <strong>MINA</strong>
part of your code is probably non significant, compared to whatever your
application will consumme. At some point, it's probably not worthful to spend
many times more energy writing a faster network layer on your own for a gain
which will be barely noticable.</p>
+ <strong>BIO</strong> is definitively faster that <strong>NIO</strong>. The
difference is something like 30% in favor of <strong>BIO</strong>. This is true
for up to a few thousands of connected users, but up to a point, the
<strong>BIO</strong> approach just stops scaling; you won't be able to handle
millions of connected users using one thread per user! <strong>NIO</strong>
can. Now, one other aspect is that the time spent in the <strong>MINA</strong>
part of your code is probably non significant, compared to whatever your
application will consume. At some point, it's probably not worthwhile to spend
the energy trying to writing a faster network layer on your own for a gain
which will be barely noticeable.</p>
</li>
<li>
<p>A proven system
- <strong>MINA</strong> is used by tens of applications all over the world.
There are some <em>Apache</em> projects based on <strong>MINA</strong>, and
they are working pretty well. This is some kind of guarantee that ypu won't
have to spend hours on some cryptic errors in your own implementation of the
network layer.</p>
+ <strong>MINA</strong> is used by many applications all over the world.
There are some <em>Apache</em> projects based on <strong>MINA</strong>, and
they are working pretty well. This gives you the ease of mind that you won't
have to spend hours on some cryptic errors in your own implementation of the
network layer.</p>
</li>
<li>
-<p>Existing supportd protocols
- <strong>MINA</strong> comes with various implemented existing protocols :
HTTP, XML, TCP, LDAP, DHCP, NTP, DNS, XMPP, SSH, FTP... At some point,
<strong>MINA</strong> can be seen not only as a <strong>NIO</strong> framework,
but as a network layer with some protocol implementation. One of
<strong>MINA</strong> feature in the near future is to offer a collection of
existing protocol you can use.</p>
+<p>Existing supported protocols
+ <strong>MINA</strong> ships with various implemented protocols: HTTP, XML,
TCP, LDAP, DHCP, NTP, DNS, XMPP, SSH, FTP... At some point,
<strong>MINA</strong> can be seen not only as a <strong>NIO</strong> framework,
but as a network layer with some protocol implementation. In the near future
<strong>MINA</strong> may offer a more extensive collection of protocols for
you to use.</p>
</li>
</ul>
