Skip to content

Commit 06d494e

Browse files
AleC-IXAleC-IX
committed
working on metrics routing
1 parent c8b0c9a commit 06d494e

9 files changed

+425
-53
lines changed

‎README.md

+39-21
Original file line numberDiff line numberDiff line change
@@ -30,27 +30,39 @@ We use RSA 2048-bit encryption, and example configurations are provided below.
3030
## User & Queue Configuration
3131

3232
Some scripts rely on `rabbitmqadmin`, so ensure that an administrator user is properly configured and that the default "guest" user is restricted to localhost access only.
33-
34-
From the `users.yaml` configuration, clients publish to the same exchange but use distinct routing keys, which correspond to their Common Name (CN) in their certificate.
35-
These routing keys determine message distribution across tiers (which act as exchanges).
36-
Each client is subscribed to its own private queue, which receives messages routed from the relevant tiers.
37-
38-
The `setup.sh` script automates the setup of queues, permissions, exchanges, and bindings as defined in `users.yaml`.
39-
Client certificates and private keys, ensuring each client can authenticate securely.
40-
41-
The `eraseRabbit.sh` script removes all queues, bindings, exchanges, and users, except for the default "guest" user, ensuring continued access via `rabbitmqadmin`.
42-
43-
The `deleteUserBindings.sh` script removes all the bindings for the user passed as argument.
44-
45-
Once the setup is over it it is possible to refine the configuration with specific `rabbitmqctl` and `rabbitmqadmin` commands to create more bindings.
46-
Previously issued certificates will continue to function as expected.
47-
48-
## Message Routing & Permissions
49-
50-
Each client can publish only using its assigned routing key to the defaultPeeringExchange and can subscribe only to its private queue.
51-
Clients are categorized into four arbitrary tiers for message routing.
52-
53-
### A simple schema that illustrates a possible broker architecture
33+
34+
Users are defined in `users.yaml` and created via `setup.sh` along with their permissions.
35+
Each client has a dedicated queue receiving messages from `routing_exchange` and publishes to `advertisement_exchange` (aggregates node IPs) and `rules_exchange` (informs the broker of filtering criteria). Messages are routed accordingly.
36+
37+
`LocalAgent` consists of two classes: `RulesManager` managing rules, and `RoutingManager` managing the advertisements.
38+
39+
`metrics.sh` updates node latency to every known client every 2 minutes in `metrics.yaml` and `RoutingManager` reads this to generate routing keys. If a client IP changes it updates both the file and the bindings.
40+
41+
Before the `RulesManager` sets up bindings, an ERP API validates client access to specific data.
42+
43+
Client authentication is secured via certificates.
44+
45+
`eraseRabbit.sh` removes all queues, bindings, exchanges, and users, except guest, and `deleteUserBindings.sh` removes all bindings for a given client.
46+
47+
After setup, additional bindings can be configured via rabbitmqctl/rabbitmqadmin.
48+
Previously issued certificates remain valid.
49+
50+
## Message format and routing
51+
52+
Two types of messages are published on the exchanges.
53+
The announcement contains the FLUIDOS node ID, including the IP.
54+
55+
The rule is a string representing the latency, bandwidth and geographical zones desired by the sender: the format is like:
56+
`100.1.K-Z-J`
57+
Where 100 is the maximum latency accepted in milliseconds, 1 is the minimum bandwidth accepted in Mbps and K, Z, J represent some geographical zones.
58+
59+
This rule is translated to three different bingding keys that will be applied with `rabbitmqctl`:
60+
- 100.1.K
61+
- 100.1.Z
62+
- 100.1.J
63+
If any message from the announcements has a routing key matching one of these bindings, that message will be routed to the queue of the client which sent the rule.
64+
65+
### A schema that illustrates broker's architecture
5466

5567
<p align="center">
5668
<img src="./docs/images/broker_server.jpg"/>
@@ -80,3 +92,9 @@ Clients are categorized into four arbitrary tiers for message routing.
8092
├─ setup.sh
8193
├─ cert_gen.sh
8294
├─ eraseRabbit.sh
95+
├─ deleteUserBindings.sh
96+
├─ router/
97+
│ ├─ metrics.sh
98+
│ ├─ metrics.yaml
99+
│ ├─ router.py
100+
│ ├─ routingRules.yaml

‎deleteUserBindings.sh

+2-2
Original file line numberDiff line numberDiff line change
@@ -15,11 +15,11 @@ BINDINGS=$(rabbitmqadmin list bindings source destination routing_key -f tsv)
1515
while IFS=$'\t' read -r SOURCE DESTINATION ROUTING_KEY; do
1616
# check if USR_NAME is contained in a destination or routing key
1717
if [[ "$ROUTING_KEY" == *"$USR_NAME"* ]]; then
18-
echo "Remove binding: Exchange '$SOURCE' → Queue '$DESTINATION' with Routing Key '$ROUTING_KEY'..."
18+
echo "Remove binding: Exchange '$SOURCE' - Queue '$DESTINATION' with Routing Key '$ROUTING_KEY'..."
1919
rabbitmqadmin delete binding source="$SOURCE" destination="$DESTINATION" destination_type="exchange" properties_key="$ROUTING_KEY"
2020
fi
2121
if [[ "$DESTINATION" == *"$USR_NAME"* ]]; then
22-
echo "Remove binding: Exchange '$SOURCE' → Queue '$DESTINATION' with Routing Key '$ROUTING_KEY'..."
22+
echo "Remove binding: Exchange '$SOURCE' - Queue '$DESTINATION' with Routing Key '$ROUTING_KEY'..."
2323
rabbitmqadmin delete binding source="$SOURCE" destination="$DESTINATION" destination_type="queue"
2424
fi
2525

‎docs/images/broker_server.jpg

9.96 KB
Loading

‎router/metrics.sh

+38
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
#!/bin/bash
2+
3+
METRICS_FILE="metrics.yaml"
4+
5+
update_latency() {
6+
local client=$1
7+
local ip=$2
8+
9+
if [[ -z "$ip" || "$ip" == "null" ]]; then
10+
echo "IP not valid for $client, skipping"
11+
return
12+
fi
13+
14+
# Pick the latency from the ping command
15+
latency=$(ping -c 4 "$ip" | awk -F'/' '/rtt/ {print $5}')
16+
17+
if [[ -n "$latency" ]]; then
18+
echo "Updating latency for $client ($ip) to $latency ms"
19+
20+
# yq to modify YAML
21+
yq eval "(.[] | select(.${client}).${client}.latency) |= $latency" -i "$METRICS_FILE"
22+
else
23+
echo "Error pinging $client ($ip)"
24+
fi
25+
}
26+
27+
while true; do
28+
# Get list client IP
29+
clients=$(yq eval '.[] | keys | .[]' "$METRICS_FILE")
30+
31+
for client in $clients; do
32+
ip=$(yq eval ".[] | select(.${client}).${client}.ip" "$METRICS_FILE")
33+
update_latency "$client" "$ip"
34+
done
35+
36+
echo "See you in 2 mins..."
37+
sleep 120
38+
done

‎router/metrics.yaml

+17
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
- clientA:
2+
digest: clientA
3+
ip: 172.18.0.6:30000
4+
latency: 100
5+
throughput: 10
6+
zone: K
7+
- clientB:
8+
digest: clientB
9+
ip: null
10+
latency: 20
11+
throughput: 200
12+
zone: Z
13+
- clientC:
14+
ip: null
15+
latency: 30
16+
throughput: 300
17+
zone: P

0 commit comments

Comments
 (0)