Housekeeping
1. Overview
The Monitoring System provides real-time insight into replication activity across vessels and shore-based installations. It alerts users when replication fails or data is missing and provides a mobile-friendly interface for on-the-go monitoring.
The possibilities and scheme of work
The proposed monitoring system has the following possibilities that are available for end users through the UI of the Android application
show the status of last replications on clients’ sites
send out alerts when the last replication on a site contains errors or when no new replication status have been received from the site for a long time;
Receive the status of replication on the main sites in real time.
Key Components
• Replicator Service – Installed on each client site to send replication status data.
• Monitoring Server – Collects data from replicators, stores it, and transmits updates to mobile apps.
• Android Application – Displays replication status and alerts for configured clients.
Interaction between Replicator, Monitoring Server, and Android users.
2. Installation
Follow the steps below to install the Monitoring Service:
1. Run the installer (example: ADONISReplMon_v2023.1.0.4.exe).
2. Select a database folder (avoid access right problems, don’t use the Program Files folder).
Selecting database location.
3. Configure ports: specify the main service port and, if required, separate ports for Android or Replicator connections.
Configuring ports for Android and Replicator connections.
The current service is designed to use one port for all incoming connections, including administering the monitoring service via a web browser. However, you can enable a separate port for Android clients and another for Replicator services. These additional ports may be necessary when Android clients or Replicator services do not support the websocket protocol (which has been added to the monitoring service since version 2023.1). The websocket protocol was introduced to allow communication with client applications through encrypted connections. If your client applications do not support the websocket protocol, enable the relevant checkbox, specify a port number, and the monitoring service will communicate with such applications via the native binary protocol as before (data transferred are not encrypted, although they are not human-readable). Check one or both checkboxes and specify a port number if you need the service to communicate with corresponding applications using the native binary protocol.
4. Provide TLS certificate files if secure connections are required (optional).
Setting up TLS certificate for secure communication.
This page determines whether connections to your server will be secure or not. The page is designed to specify a TLS certificate of the host machine where you are installing the monitoring service. You must specify a path to a valid TLS certificate file and a matching private key file on this page if you want all communication with the monitoring service to be secure, meaning it should run via encrypted TLS tunnels. If you do not have a valid certificate or do not need secure connections, you should leave both paths empty. In this case, the monitoring server can still communicate with client applications using the websocket protocol, but without encryption.
5. Set administrator credentials (username: admin).
Setting administrator password.
6. Choose an installation folder (default: %ProgramFiles%).
Selecting installation folder.
3. Service Setup
After installation, log in to the Monitoring Service using a web browser:
URL format: <scheme>://<server_address>:<port_number> (e.g., https://localhost:5002)
Enter the administrator credentials set during installation to access configuration settings.
Monitoring Service login page.
Clients Setup
Each client represents a group of sites replicating data. Configure clients using the following fields:
• Client Name – Display name.
• Short Name – Max 6 characters.
• Repl Login / Repl Password – Used by the Replicator to connect.
Follow the rule 'one client – one login' to avoid mixed replication data.
[Fig09] – Client configuration page.
Android Users
Create unique logins for each Android device. Assign access per client and control visibility using the ‘Access to everyone’ option. Note: Firefox users may need to refresh the user list once to display content correctly.
Android Users configuration page.
4. Replicator Configuration
Monitoring parameters are configured in the Replicator settings wizard. Replicators send replication events—metadata describing replication success, warnings, or errors.
Replication events are written to heartbeat files (*.HRB) and sent to the monitoring server or to the main site.
When setting up the replicator, you need to choose a way of delivering replication events to the monitoring service. There are two ways which replication events can be delivered to the monitoring service:
through a direct TCP connection established between the replicator and monitoring service;
via the main site.
When on a satellite, replication events can be sent to the main site first. Then, the Replicator on the main site resends the heartbeat files it receives to the monitoring server via its direct connection.
The replicator events (heartbeat files) do not contain any database content; they only constrain the replicator status.
Monitoring settings page in the Replicator wizard.
Choose one of the following delivery options:
1. Connect directly to the Monitoring Server.
2. Send heartbeat files to the main site (for satellite locations).
3. Do not send events.
Main sites must always connect directly to the server. Satellites may forward heartbeat files if offline or with unstable internet.
Example configuration: main site and vessels.
The main site and office two are connected to the monitoring server and transfer their replication events through direct connections. Vessels A, B and C send their replication events to the main site, which resends them to the server
5. Monitoring Server Settings
The Replicator must connect to the Monitoring Server using credentials defined in the Service Setup. Configure the following fields:
Monitoring server connection configuration.
• Server URI – Format: ws(s)://<host>:<port>/ws/repl
• Port – Port number used during installation.
• User Name / Password – Use the client’s Repl Login and Password.
• Protocol – Choose ‘wss’ for secure connections or ‘ws’ for open connections.
If the checkmark “Use a separate port for Replicator services” was unchecked when installing the monitoring service, the replicator must connect to the service on the websocket protocol through the standard port specified in the field “Port for any incoming connection” (f Choose the corresponding option in the radio group and specify the port number in the field Server URL in the screen below.
Example of WebSocket connection settings.
An example of a correctly specified address in 'Server URI'.
Sample Server URI entry.
wss vs ws (web socket secure vs web socket protocol)
If you set up your monitoring server to serve incoming connections through secure, encrypted tunnels (i.e. you specified a valid TLS certificate when installing your service), then you must specify wss as a schema in the field “Server URI” (WebSocket Secure Protocol). If your server uses the open WebSocket protocol for incoming connections (TLS certificate is not specified or invalid), then specify ws as a scheme (WebSocket protocol).
If using native binary protocol, use the non-websocket port configured during installation.
If the checkmark “Use a separate port for Replicator services” was checked when installing the monitoring service, the replicator must connect to the server on the native binary protocol through the port specified in the field “Non-websocket port for Replicator connections” of the service installation wizard.
Choose the corresponding option in the radio group and specify the port number in the field “Port” below.
Setting up native (non-websocket) connection.
For the “User Name” and “Password” fields, use the Repl Login and Password that you specified for the current client when setting up the monitoring service. Pay your attention that the “Test connection” button only checks the server availability on the chosen protocol. The values of User Name and Password are not used when testing a connection.
The ‘one client – one login’ rule requires that all the replicators of one client use the same login to connect to the monitoring service. In the example shown on fig. 12, the main site and office 2 use the same login to connect to the monitoring service.
6. Android Application Setup
1. Install the APK file (Adonis_1.0.0.*.apk) on your Android device.
2. Log in using credentials from the ‘Android Users’ section of the Monitoring Service.
Android login screen.
3. Configure the server connection parameters:
Set the connection parameters to the monitoring server according to the settings you specified during service installation (see the Monitoring Service Installation section).
If the checkmark “Use a separate port for Android clients” was unchecked when installing the monitoring service, the application must connect to the service on the websocket protocol through the common port specified in the field “Port for any incoming connection” . Choose the corresponding option and specify the port number if the websocket support has been added to the application.
The field “Server URI” (if available) has the same format and is filled in the same way as that field in the replicator settings wizard (see above). The only difference is the path component. The server’s resource “/ws/android” is intended for Android clients only. So, set the path to “/ws/android”.
An example of a correctly specified address in “Server URI”:
wss://somehost.com:5001/ws/android
If the checkmark “Use a separate port for Android clients” was checked when installing the monitoring service, the application must connect to the service on the native binary protocol through the port specified in the field “Non-websocket port for Android client connections” (fig. 4). Take the following setup steps:
a. Press ⁞ symbol at the right top corner and select ‘Set server address’ item (fig. 18);
b. Specify IP address of your monitoring server;
c. Specify the port number that you specified as “Non-websocket port for Android client connections” when installing the monitoring service (fig. 4).
After you have taken these steps, the list of available clients will be shown. For each of these clients, you will be able to see its sites, list of recent replications and receive notifications.
- Server URI format: wss://yourserver.com:5001/ws/android
- If a separate Android port is used, specify the IP and port under ‘Set server address’.
Setting the server address on an Android device.
Once connected, the app displays available clients, sites, and replication statuses, and issues alerts for errors or missing updates.
7. Appendix
**Glossary:**
• Replication Event – Metadata describing a single replication.
• Heartbeat File (*.HRB) – A file containing replication event details sent to the monitoring server.
• Native Protocol – Unencrypted binary communication protocol used when websocket support is unavailable.
**Version History:** Edition 2, 2023. Updated for websocket support and TLS integration.
8. Additional Technical Background
💡 **Background – TLS and Secure Connections**
TLS encrypts communication between the Monitoring Server, Replicators, and Android clients. If omitted, connections remain functional but unencrypted—suitable only for isolated shipboard LAN environments.
💡 **Background – WebSocket vs Native Protocol**
WebSocket (ws/wss) provides real-time two-way communication, while the legacy native binary protocol sends lightweight event data. Both can coexist, enabling compatibility with older Replicators.
🌐 **Network Topology Overview**
Main sites connect directly to the Monitoring Server, while satellites forward heartbeat (.HRB) files to the main site. This minimizes bandwidth usage and allows centralized control.
⚙️ **Replication Event Structure**
Each replication event includes Sequence ID, Timestamp, Event Type, and Parameters. It never contains personal or payroll data—only metadata used for monitoring.
🔒 **Authentication and Permissions**
Each client has a unique Repl Login and Password. Mixing logins between clients merges replication streams, leading to data confusion. Android users should each have individual credentials to ensure accurate monitoring logs.