Saga of Netty ( Part 1 – Theoretical Introduction )

Table of contents
Reading Time: 3 minutes

Why explore Netty? Before starting a series of blog posts about Netty this is an obvious question. If you love to develop distributed or high throughput or big data applications with the help of already crafted libraries and SDKs and have a thirst to know how actually they are built, then you should probably start learning how the distributed systems interact (connect and transfer data) with each other to create a reactive environment. Netty is one of such frameworks to link all the distributed parts of such applications.

Netty is an NIO client-server framework, which enables quick and easy development of network applications, such as protocol servers and clients. Netty offers you a new way to develop your network applications, which makes it easy and scalable. It achieves this by abstracting away the complexity involved and by providing an easy-to-use API that decouples business-logic from the network-handling code. Because it s built for NIO (Non-blocking IO), the entire Netty API is asynchronous.

High-profile companies and open-source projects including RedHat, Twitter,  Infinispan, HornetQ, Vert.x, Finagle, Akka, Apache Cassandra, Elasticsearch, and others (a big list of big names) use and contribute to Netty. It s also fair to say that some of the features of Netty are a result of the needs of these projects. Over the years, Netty has become more widely known and is one of the most-used networking frameworks for the JVM, as evident by its use in several popular open- and closed-source projects.

The expansion of web has increased the need for networking applications that handle humongous amount of requests, process and store data (in a day) that one can’t read and watch in at least one year. See: What YouTube Looks Like In A Day. So, efficiency is the major demand of users. Nobody wants to wait (even for 5 sec of YouTube ad 😜 ).

The blocking IO uses one thread to cater one request i.e. the number of connections to our application are limited by the threads JVM can create, a simple application would be a client/socket chat application we wrote in our colleges.


On the other hand Non blocking IO let’s handle more than one connections. Netty uses a combination of Java Futures and method callbacks to perform NIOs. Java Futures are different from Scala Futures in that we’ve to check the state of the Java Future in intervals to check if the work is done or not. So it’s a little messy to use Java Future.

Netty is based on Java’s NIO API to open/close connection to a socket/file. NIO API uses a selector based approach to handle data and connections [Recommended read:  Java NIO Selector]. A channel represents a connection to an entity that is capable of performing an IO operation and a selector is an NIO component that keeps looking for available channel(s) to perform the IO operation. Thus a single selector (on a single thread) can handle multiple connections and save our application from latency.


The next blog posts, coming soon, will contain more information about Netty and the code implementing the client and server, both in Java and Scala. I’ll try my best to make this series rich in content and knowledge.


Written by 

Principal Architect at Knoldus Inc