andreacavalli/netty5
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Fix wording in "Universal Asynchronous I/O API" section.

Browse Source
This commit is contained in:
Evan Meagher 2011-10-03 20:32:59 -07:00 committed by Trustin Lee
parent d1a15c9aff
commit 56d6217b53
1 changed files with 23 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
src/docbook/en-US/module/architecture.xml
View File

@ -84,7 +84,7 @@
<section>
<title>Universal Asynchronous I/O API</title>
<para>
Traditional I/O APIs in Java provided different types and methods for
Traditional I/O APIs in Java provide different types and methods for
different transport types. For example,
<classname>java.net.Socket</classname> and
<classname>java.net.DatagramSocket</classname> do not have any common
@ -93,32 +93,33 @@
</para>
<para>
This mismatch makes porting a network application from one transport to
the other tedious and difficult. The lack of portability between
transports becomes a problem when you need to support more transports not
rewriting the network layer of the application. Logically, many protocols
can run on more than one transport such as TCP/IP, UDP/IP, SCTP, and
serial port communication.
another tedious and difficult. The lack of portability between
transports becomes a problem when you need to support additional
transports, as this often entails rewriting the network layer of the
application. Logically, many protocols can run on more than one
transport such as TCP/IP, UDP/IP, SCTP, and serial port communication.
</para>
<para>
To make the matter worse, Java New I/O (NIO) API introduced the
incompatibility with the old blocking I/O (OIO) API, and so will NIO.2
(AIO). Because all these APIs are different from each other in design
and performance characteristics, you are often forced to determine which
API your application will depend on before you even begin the
implementation phase.
To make matters worse, Java's New I/O (NIO) API introduced
incompatibilities with the old blocking I/O (OIO) API and will continue
to do so in the next release, NIO.2 (AIO). Because all these APIs are
different from each other in design and performance characteristics, you
are often forced to determine which API your application will depend on
before you even begin the implementation phase.
</para>
<para>
For instance, you might want to start with OIO because the number of
clients you are going to serve will be very small and writing a socket
server using OIO is much easier than using NIO. However, you are going
to be in trouble when your business grows up exponentially and your server
starts to serve tens of thousand clients simultaneously. You could
start with NIO, but it might take much longer time to implement due to
the complexity of the NIO Selector API, hindering rapid development.
to be in trouble when your business grows exponentially and your server
needs to serve tens of thousands of clients simultaneously. You could
start with NIO, but doing so may hinder rapid development by greatly
increasing development time due to the complexity of the NIO Selector
API.
</para>
<para>
Netty has a universal asynchronous I/O interface called &Channel;, which
abstracts away all operations required to point-to-point communication.
Netty has a universal asynchronous I/O interface called a &Channel;, which
abstracts away all operations required for point-to-point communication.
That is, once you wrote your application on one Netty transport, your
application can run on other Netty transports. Netty provides a number
of essential transports via one universal API:
@ -144,16 +145,15 @@
</para>
</listitem>
</itemizedlist>
Switching from one transport to the other usually takes just a couple
Switching from one transport to another usually takes just a couple
lines of changes such as choosing a different &ChannelFactory;
implementation.
</para>
<para>
Also, you are even able to take advantage of a new transport which is
not written yet, serial port communication transport for instance, again
Also, you are even able to take advantage of new transports which aren't
yet written (such as serial port communication transport), again
by replacing just a couple lines of constructor calls. Moreover, you can
write your own transport by extending the core API because it is highly
extensible.
write your own transport by extending the core API.
</para>
</section>