|
12 | 12 | - [Build and run](#build-and-run) |
13 | 13 | - [Configuration](#configuration) |
14 | 14 | - [Distributed Scenario](#distributed-scenario) |
15 | | - - [Important](#important) |
16 | 15 | - [Local Scenario](#local-scenario) |
| 16 | + - [Forwarding over TCP](#forwarding-over-tcp) |
17 | 17 | - [Network Magic](#network-magic) |
18 | 18 | - [Requests](#requests) |
19 | 19 | - [Logging](#logging) |
|
27 | 27 |
|
28 | 28 | ## Motivation |
29 | 29 |
|
30 | | -Previously, the node handled all the logging by itself. Moreover, it provided monitoring tools as well: two web-servers, for Prometheus and for EKG monitoring page. `cardano-tracer` is a result of _moving_ all the logging/monitoring-related stuff from the node to a separate service. As a result, the node became smaller, faster, and simpler. |
| 30 | +Previously, the node handled all the logging by itself. Moreover, it provided monitoring tools as well: two web-servers, for Prometheus and for EKG monitoring page. `cardano-tracer` is a result of _moving_ all logging and monitoring related functionality from the node to a separate service. As a result, the node becomes smaller, more efficient, and simpler. |
31 | 31 |
|
32 | 32 | ## Overview |
33 | 33 |
|
@@ -82,8 +82,6 @@ Distributed scenario is for real-life case: for example, you have `N` nodes work |
82 | 82 |
|
83 | 83 | Local scenario is for testing case: for example, you want to try your new infrastructure from scratch, so you run `N` nodes and one `cardano-tracer` process on your machine. |
84 | 84 |
|
85 | | -**IMPORTANT NOTICE**: Please note that `cardano-tracer` **does not** support connection via IP-address and port, to avoid unauthorized connections. The **only** way to establish connection with the node is the local socket (Unix sockets or Windows named pipes). |
86 | | - |
87 | 85 | ## Distributed Scenario |
88 | 86 |
|
89 | 87 | This is an example with 3 nodes and one `cardano-tracer`: |
@@ -251,8 +249,36 @@ There is another way to connect `cardano-tracer` to your nodes: the `cardano-tra |
251 | 249 |
|
252 | 250 | As you see, the tag in `network` field is `ConnectTo` now, which means that `cardano-tracer` works as a client: it _establishes_ network connections with your local nodes via the local sockets `/tmp/cardano-node-*.sock`. In this case each socket is used by a particular node. |
253 | 251 |
|
| 252 | +`AcceptTo` and `ConnectTo` are mirrored by the reciprocal CLI option on the node `--tracer-socket-path-connect` / `--tracer-socket-path-accept`. If you choose one on the node, you choose the opposite on the tracer. This only makes a difference to which entity initiates the handshake; after the handshake the configuration is identical |
| 253 | + |
254 | 254 | Please use `ConnectTo`-based scenario only if you really need it. Otherwise, it is **highly recommended** to use `AcceptAt`-based scenario. The reason is easier maintainance. Suppose you have 3 working nodes, and they are connected to the same `cardano-tracer`. And then you want to connect 4-th node to it. If `cardano-tracer` is configured using `AcceptAt`, you shouldn't change its configuration - you just connect your 4-th node to it. But if `cardano-tracer` is configured using `ConnectTo`, you should add path to 4-th socket in its configuration file and then restart `cardano-tracer` process. |
255 | 255 |
|
| 256 | +## Forwarding over TCP |
| 257 | + |
| 258 | +In addition to forwarding over sockets, forwarding over TCP/IP is supported. In both cases, the 'forwarding protocol' is identical. For TCP forwarding, adjust the following (only showing the `AcceptAt` scenario here): |
| 259 | + |
| 260 | +Change node CLI option: |
| 261 | +```bash |
| 262 | +--tracer-socket-network-connect 10.0.0.2:34567 |
| 263 | +``` |
| 264 | + |
| 265 | +Adjust value for `network` in `cardano-tracer`'s configuration: |
| 266 | +```yaml |
| 267 | +network: |
| 268 | + tag: AcceptAt |
| 269 | + contents: "0.0.0.0:34567" |
| 270 | +``` |
| 271 | +
|
| 272 | +In this example, `cardano-tracer` listens on port 34567. Nodes can connect via IPv4 for forwarding, with `10.0.0.2` being `cardano-tracer`'s IP in that example. |
| 273 | + |
| 274 | +### Important |
| 275 | + |
| 276 | +On same-host setups sockets are always preferrable due to **less overhead and better performance**. On multi-host setups, socket connection via SSH tunnels is always preferrable due to **increased security**. |
| 277 | + |
| 278 | +Use TCP forwarding **if and only if** you control each and every aspect of the environment, such as port mapping or firewalls, or virtual network setup - the 'forwarding protocol' does not implement encrypting traffic nor authentication methods. |
| 279 | + |
| 280 | + |
| 281 | + |
256 | 282 | ## Network Magic |
257 | 283 |
|
258 | 284 | The field `networkMagic` specifies the value of network magic. It is an integer constant from the genesis file, the node uses this value for the network handshake with peers. Since `cardano-tracer` should be connected to the node, it needs that network magic. |
|
0 commit comments