Netty Architectural Overview--reference

Reference from:http://docs.jboss.org/netty/3.1/guide/html/architecture.html

2.1. Rich Buffer Data Structure

2.2. Universal asynchronous I/O API

2.3. Event Model based on the Interceptor Chain Pattern

2.4. Advanced components for more Rapid development

2.4.1. CODEC Framework

2.4.2. SSL/TLS support

2.4.3. HTTP implementation

2.4.4. Google Protocol Buffer Integration

2.5. Summary

In this chapter, we'll examine what core functionalities is provided in Netty and how they constitute a complete networ K Application development stack on top of the core. Please keep the diagram in mind as the read this chapter.

2.1. Rich Buffer Data Structure

Netty uses its own buffer API instead of NIO to ByteBuffer represent a sequence of bytes. This approach have significant advantage over using ByteBuffer . Netty ' s new buffer type, have been designed from ground to address the problems of and to ChannelBuffer ByteBuffer meet the Daily nee DS of Network application developers. To list a few cool features:

• You can define your buffer type if necessary.

• Transparent Zero copy is achieved by built-in composite buffer type.

• A Dynamic buffer type is provided Out-of-the-box, whose capacity are expanded on demand, and just like StringBuffer .

• There ' s no need to call flip() anymore.

• It is often faster than ByteBuffer .

For more information, please refer to the package org.jboss.netty.buffer description.

2.2. Universal asynchronous I/O API

Traditional I/O APIs in Java provided different types and methods for different transport types. For example, and does not has any java.net.Socket java.net.DatagramSocket common super type and therefore they has very different ways to perform Socke t i/O.

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

To make the matter worse, Java New I/O (NIO) API introduced the incompatibility with the old blocking I/O (OIO) API, and S O'll nio.2 (AIO). Because all these APIs is different from the other in design and performance characteristics, you is often forced to de Termine which API your application would depend on before you even begin the implementation phase.

For instance, might want-to-start with OIO because the number of clients is going to serve would be very small and Writing a socket server using OIO is much easier than using NIO. However, you is going to being 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, h Indering rapid development.

Netty has a universal asynchronous I/O interface called Channel , which abstracts away all operations required to POINT-TO-PO int communication. That's, once 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:

• nio-based TCP/IP transport (see org.jboss.netty.channel.socket.nio ),

• oio-based TCP/IP transport (see org.jboss.netty.channel.socket.oio ),

• Oio-based UDP/IP Transport, and

• Local Transport (see org.jboss.netty.channel.local ).

Switching from one transport to the other usually takes just a couple lines of changes such as choosing a different implementation.

Also, even able to take advantage of a new transport which was not written yet, serial port communication transport For instance, again by replacing just a couple lines of constructor calls. Moreover, can write your own transport by extending the core API because it's highly extensible.

2.3. Event Model based on the Interceptor Chain Pattern

Well-defined and extensible event model is a must for a event-driven application. Netty does has a well-defined event model focused on I/O. It also allows implement your own event type without breaking the existing code at all because each event type is D istinguished from strict type hierarchy. This is another differentiator against and other frameworks. Many NIO frameworks have no or very limited notion of event model; They often break the existing code when you try to add a new custom event type, or just does not allow extension.

A is ChannelEvent handled by a list of ChannelHandler s in a ChannelPipeline . The pipeline implements an advanced form of the intercepting Filter pattern to give a user Full control over how an event is handled and how the handlers in the pipeline interact with each other. For example, you can define the what-if a data is read from a socket:

SimpleChannelHandler{Public    void messagereceived ( ChannelHandlerContext MessageEvent evt) {        Object message = Evt.getmessage ();        Do something with the received message.        ...        And forward the event to the next handler.        Ctx.sendupstream (EVT);}    }

You can also define how to does when other handler requested a write operation:

SimpleChannelHandler{Public    void writerequested ( ChannelHandlerContext MessageEvent evt) {        Object message = Evt.getmessage ();        Do something with the message to be written.        ...        And forward the event to the next handler.        Ctx.senddownstream (EVT);}    }

For more information on the event model, please refer to the API documentation of ChannelEvent and ChannelPipeline .

2.4. Advanced components for more Rapid development

On top of the core components mentioned above, which already enable the implementation of all types of the network applications , Netty provides a set of advanced features to accelerate the development pace even more.

2.4.1. CODEC Framework

As demonstrated in sections 1.8, "Speaking in POJO instead of Channelbuffer", it's always a good idea to separate a prot Ocol codec from a business logic. However, there is some complications when implementing the idea from scratch. Deal with the fragmentation of messages. Some protocols is multi-layered (i.e. built on top of the other lower level protocol). Some is too complicated to be implemented

Consequently, a good network application framework should provide an extensible, reusable, unit-testable, and Multi-layere D codec framework that generates maintainable user codec.

Netty provides a number of basic and advanced codecs built on top of it core to address most issues you'll encounter WH En you write a protocol codec regardless if it's simple or not, binary or text-simply whatever.

2.4.2. SSL/TLS support

Unlike old blocking I/O, it is a non-trivial task to support SSL in NIO. You can ' t simply wrap a stream to encrypt or decrypt data and you had to use it. is a state machine which is as javax.net.ssl.SSLEngine SSLEngine Complex as SSL is. Manage all possible states such as cipher suite and encryption key negotiation (or re-negotiation), Certificat E Exchange and validation. Moreover, is not SSLEngine even completely thread-safe unlike usual expectation.

In Netty, takes care of all the SslHandler gory details and pitfalls of SSLEngine . All your need to configure and inserts the to SslHandler your ChannelPipeline . It also allows implement advanced features likestarttls very easily.

2.4.3. HTTP implementation

HTTP is definitely the most popular protocol in the Internet. There is already a number of HTTP implementations such as a Servlet container. Then why does Netty has HTTP on top of its core?

Netty ' s HTTP support was very different from the existing HTTP libraries. It gives all control over how HTTP messages is exchanged in a low level. Because It is basically the combination of HTTP codec and HTTP message classes, there is no restriction such as enforced t Hread model. That's, you can write your own HTTP client or server that works exactly the the the-the-same-want. You have the full control over the thread model, connection life cycle, chunked encoding, and as much as what HTTP specification a Llows.

Thanks to it highly customizable nature, you can write a very efficient HTTP server such as:

• Chat server that requires persistent connections and server push technology (e.g. Comet)

• Media streaming server, needs to keep, the connection open until the whole media is streamed (e.g. 2 hours of movie)

• File server that allows the upload of large files without memory pressure (e.g. uploading 1GB per request)

• Scalable mash-up client that connects to tens of Thousand 3rd party Web services asynchronously

2.4.4. Google Protocol Buffer Integration

Google Protocol Buffers is an ideal solution for the rapid implementation of a highly efficient binary Protocol that Evol Ves over time. ProtobufEncoder ProtobufDecoder with and, can turn the message classes generated by Google Protocol buffers Compiler (PROTOC) into Netty C Odec. LocalTime ' examplethat shows how easily can create a high-performing binary protocol Clie NT and server from the sample protocol definition.

2.5. Summary

In this chapter, we reviewed the overall architecture of Netty from the feature-wise standpoint. Netty have simple yet powerful architecture. It is composed of three Components-buffer, channel, and event Model-and all advanced features be built on top of the Three core components. Once understood how these three work together, it should is difficult to understand more advanced features which W Ere covered briefly in this chapter.

You might still has an unanswered question about what the overall architecture looks exactly like and how each feature Wo RK together. If So, it's a good idea-to-talk to us-to-improve this guide.

Netty Architectural Overview--reference