Entwicklung von Netzwerkapplikationen mithilfe von Netty

Network Programming the easy Way


Netzwerkapplikationen zu schreiben, die auch noch skalierbar und hochperformant sind, ist und war ein schwieriges Unterfangen. Netty hat es sich zur Aufgabe gemacht, hierbei unterstützend zur Hand zu gehen.

Netty [1] ist ein eventgetriebenes Framework, das es erlaubt, Netzwerkprogramme zu schreiben, die komplett asynchron sind und somit nicht beim Warten auf neue Pakete blockieren. Hierbei versucht es die meiste Komplexität vor dem Benutzer/Entwickler zu verbergen und somit die Produktivität zu steigern. Diese vierteilige Artikelserie setzt den Schwerpunkt auf die Darstellung, wie Netty helfen kann, verschiedenste Netzwerkapplikationen umzusetzen.

Artikelserie

Teil 1: Entwicklung von Netzwerkapplikationen
Teil 2: Mit Netty WebSockets unterstützen
Teil 3: Netty via SPDY
Teil 4: Neues in Netty 4.0.0

Netty war bis vor Kurzem ein JBoss-Projekt, wurde jedoch eigenständig, als sein Erfinder Trustin Lee Red Hat verließ und zu Twitter wechselte. Trotzdem wird Netty immer noch in JBoss-Projekten eingesetzt. Es steht unter der Apache License 2.0 [2] und ist somit auch ohne Bedenken in kommerziellen Applikationen einsetzbar. Aktuell ist die Version 3.5.3. Final, wobei die erste Alphaversion der 4.x-Serie veröffentlicht wurde. Da aber 4.0.0. Final noch fern ist, befasst sich dieser Artikel mit der 3.x-Serie von Netty, die im Moment die Wahl ist, wenn Sie ein stabiles API bzw. eine stabile Library erwarten.

Warum NIO/asynchron?

Jetzt fragen sich einige von Ihnen sicher: warum NIO [3]/asynchron? Es ging doch auch immer ohne... Das stimmt, es geht auch ohne, aber Skalierung ist nur bedingt möglich. Dies resultiert daraus, dass bei einer herkömmlichen Netzwerkapplikation eine 1:1-Beziehung zwischen Verbindung und Thread besteht. Leider warten die Threads die meiste Zeit auf Ressourcen (wie z. B. Netzwerk) und können somit nicht effektiv genutzt werden. Das ist nicht weiter problematisch und funktioniert durchaus gut, solange die Anzahl gleichzeitiger Verbindungen eher gering ist. Aber sobald wir von Zehntausenden gleichzeitiger Verbindungen reden, sieht die Sache schon anders aus. Zwar ist es heute durchaus möglich, Tausende von Threads in einer JVM laufen zu haben, aber der Overhead des „Context-Switching“ zwischen den Threads fällt durchaus ins Gewicht. Des Weiteren wird Speicher verbraucht, der für andere Sachen genutzt werden kann und auch sollte.

Stellen Sie sich vor, Sie müssten einen Koch pro bestelltem Gericht vorhalten, da er immer nur ein Gericht gleichzeit...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang