Babl server is composed of two main parts - the session container, which handles web-socket connections, and the application an implementation of the Application interface that implements business logic.

The session container performs network I/O and protocol translation, sending received messages to the application.

The application returns messages to a session via the session container, where it will be fragmented if necessary, and converted back into the web-socket protocol.

The session container tracks liveness of sessions, sending PING messages and receiving PONG messages on the application's behalf.

The session container also maintains statistics relating to active sessions and to the server as a whole. More information can be found in Monitoring.

Depending on deployment and scaling requirements, the session container can operate in DIRECT mode, where non-blocking network I/O and protocol translation is performed on the same thread as application message processing.

DIRECT mode is useful for simple deployments when sufficient client connections can be handled on a single thread. Alternatively, for completely stateless applications that are merely gateways to a stateful back-end, multiple instances of the session container can be run.

For better scalability, Babl can be configured to run in DETACHED mode where multiple session containers communicate with a single application instance over an efficient IPC mechanism. I/O and protocol translation can be scaled horizontally, while still allowing the application to run in a single-threaded context.

Deployment mode is selected by setting the following system property on the command-line, or in a configuration file:

babl.server.deployment.mode

Valid values are:

• DIRECT
• DETACHED

Direct mode

In DIRECT mode, your application logic is executed directly as messages are received from web-socket clients. Sessions are processed in the order provided by the operating system in response to an epoll call.

Detached mode

In DETACHED mode, one or more session containers will send received messages to the application over Aeron IPC. The application container will poll the IPC transport for new messages, and pass them to the application. Responses are sent to a Session using the send method, and delivered to the originating session container over IPC.

Sending to a session will return a SendResult value, which must be checked by the application. In the event that session containers are not able to keep up with the message flow out of the application, the send method will return SendResult.BACK_PRESSURE. It is up to the application to decide what to do at this point, depending on application delivery guarantees.

Multi-Runtime Support

Messages exchanged between the session container and the application are encoded using SBE, so any supported language runtime using Aeron (via C FFI or native client) can host the application logic. This makes the session container a runtime- and language-agnostic web-socket server.