# Internal Networking Guide

## Introduction

This guide aims to give developers an overview of the low-level Netty-based networking in Openfire. It is not necessary for administrators of Openfire to read or understand this. It includes detailed information for developers that wish to understand, or make changes to, the Openfire source code.

For additional developer resources please see the Netty 4 user guide and the Netty 4 JavaDoc.

Topics that are covered in this document:

## Netty Architecture

The following diagram shows the generic architecture of Netty. There is nothing specific to Openfire shown in the diagram, but it is hoped that this will be a useful model for developers to picture when working with Netty in Openfire.

The generic Netty architecture.

## Netty in Openfire

In the diagram below we can start to understand how Netty is used in Openfire.

We see that Openfire's ConnectionManagerImpl creates various Connection Listeners that handle connections for the various connection types in Openfire, differentiated by port number, for example Server to Server (S2S) using STARTTLS, Client to Server (C2S) using STARTTLS, S2S using Direct TLS,C2S using Direct TLS, etc.

These Connection Listeners each create new NettyConnectionAcceptors which bootstraps networking connection listeners using Netty.

In addition to Netty's standard acceptor (boss) and I/O worker event loop groups, Openfire introduces a dedicated executor for handlers that may perform blocking or long-running operations. This executor is shared across all channels created by a connection acceptor and is used to ensure that Netty EventLoop threads remain strictly non-blocking and responsive.

How Netty fits into Openfire.

Zooming in on the above diagram to the S2S and C2S child-group channel pipelines we can see specific ChannelHandler implementations that handle TLS, XMPP stanza decoding, stalled session logic, and the core Openfire "business logic". While protocol framing and I/O-related handlers execute on Netty's I/O worker event loops, handlers that may perform blocking or long-running work (such as authentication, routing, or persistence) are explicitly offloaded to a dedicated blocking handler executor.

A close-up view of Netty child-channel pipelines in Openfire.

## Server Bootstrapping in Openfire

The following sequence diagram shows how Netty is bootstrapped as part of the XMPPServer bootstrapping process. It aims to add enough detail, on top of the information presented above, to enable developers to orientate themselves in the codebase and discover the finer details of the Netty-based connection and channel handling system within Openfire.

Netty bootstrapping in Openfire.

Note that the source for this diagram is available in the Openfire source repository.

## Message Handling with Netty in Openfire

The final sequence diagram shows how Openfire handles network messages using Netty. It aims to add enough detail, on top of the information presented above, to enable developers to orientate themselves in the codebase and discover the finer details of the network message processing and stanza parsing systems within Openfire.

It is important to note that not all message processing occurs on Netty EventLoop threads. While socket reads and writes are handled by the I/O worker event loops, Openfire ensures that handlers which may block or take significant time to execute are invoked on a separate blocking handler executor. This design prevents EventLoop starvation and ensures consistent throughput under load.

How Openfire handles messages with Netty.

Note that the source for this diagram is available in the Openfire source repository.