Babl server is composed of two main parts - the session container, which handles web-socket
and the application an implementation of the
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
PONG messages on the application's behalf.
The session container also maintains statistics relating to active sessions and to the server as a
More information can be found in Monitoring.
Depending on deployment and scaling requirements, the session container can operate in
where non-blocking network I/O and protocol translation is performed on the same thread as application
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
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:
Valid values are:
DIRECT mode, your application logic is executed directly as messages are
from web-socket clients. Sessions are processed in the order provided by the operating
system in response to an epoll call.
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
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
In the event that session containers are not able to keep up with the message flow out of the
the send method will return
It is up to the application to decide what to do at this point, depending on application delivery
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.