Netty 2 1.3 Released: Event-driven NIO Framework

Discussions

News: Netty 2 1.3 Released: Event-driven NIO Framework

  1. Netty 2 provides an easy event-based API (like Swing) to develop high-performance, maintainable TCP/IP server/client application. Netty provides many essential features such as readiness selection, thread pooling, write buffer DoS prevention, and buffer reuse which are required to build high- performance and capacity network applications.

    New Features:

    * 'Write buffer full' prevention:
      * Detects too slow clients
      * Throttles outgoing messages to avoid resource shortage
    * JMX-compliant: Thread pools and common configuration are MBean.
    * The priority of all threads are now configurable on-the-fly.

    Full Feature list:

    * Event-based API: Netty handles all low level I/O call
    * Separation of message format and workflow
    * Protocol messages are represented as classes: Protocol implementation in object-oriented way!
      * Polymorphism enables 'pluggable protocol'.
      * Inheritance enables 'message part hierarchy'.
    * Java NIO: Better scalability
    * Built-in thread pool:
      * I/O and event processing threads are separated.
      * All thread priorities are configurable.
    * Direct byte buffer pooling: No direct buffer allocation overhead
    * Customizable event dispatcher: Flexible thread scheduling
    * 'Write buffer full' prevention:
      * Detects too slow clients
      * Throttles outgoing messages to avoid resource shortage
    * JMX-compliant: Thread pools and common configuration are MBean.

    Check Netty 2 At: http://gleamynode.net/dev/projects/netty2/

    Threaded Messages (6)

  2. Design goals[ Go to top ]

    Looks like an interesting project. Is it designed for low latency and/or high throughput? For example, would it be useful for an online game with 1000 clients (where low latency is crucial)?
  3. Design goals[ Go to top ]

    The default thread model of Netty 2 is RWP (Read/Write and Process) pool model that I/O thread pool and event dispatcher thread pool are separated. So I can say that the default thread model Netty 2 provides is not for very low latency.

    RWP pool model is useful where many connections are expected with variable I/O sizes, or where the business logic involves time-consuming operations such as DB processing that requires the separated thread pool.

    I chose RWP pool model because I thought the ideal number of I/O threads and event processing threads are usually different, because the limiting factor of Socket I/O is the number of CPU, and the limiting factor of nowaday's business logic is other resources such as disk, database, or other subsystems.

    But, please note that you can fulfill significantly low latency if you program your own event dispatcher. Well, I'd better add that one in the next release! ;)

    Thank you very much for your interest!!!
  4. Design goals[ Go to top ]

    I found it very interesting as I understand it can be very usefull to implement adapter or client for "legacy" protocol in enterprise too.
  5. Design goals[ Go to top ]

    Yes, that's right. I made Netty to implement legacy protocols catching up tight schedule. ;)
  6. Is this related at all to Ember IO from Mike Spille? I'm just curious how the architecture compares .. comments?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  7. Netty 2 is evolved from Netty 1 which uses pre1.4 I/O API. Please check Netty 1 at http://milkbox.sf.net/ So Netty 2 is developed independent from EmberIO. When Netty 2 1.0 is almost released, I was Mike Spille's article about NIO, so I included some of his ideas in the next versions of Netty 2. Lots of thanks to Mike! ;)