Replace networking stack with etcd-based approach #1720
Comments
ch1bo
added
green 💚
|
What is the difference between our use and cardano-node's use of ouroboros that causes us to seek out this alternate solution? Why can we not improve things there? |
|
I think, indeed, we could use cardano-style networking, but that would again be wildly upping the difficulty of the task. What we have right now was, I suppose, basically just the bare minimum to get it working. This task improves on that somewhat with some more deliverability features; and we know if fixes a problem we care about ; i.e. #1786. I think in some sense our whole approach to Hydra, and it's networking, could be different and could've focused on direct re-use of the actual cardano-node binary; but given where we are this is a fine incremental improvement, in my view. |
|
I have created this task, assuming we want to address the use of the CLI with a recommended approach #1843 |
@locallycompact We only (mis-)use the same framework to actually send out CBOR-encoded messages over TCP in a fully connected topology. Over this, we tried (and failed?) to implement reliable broadcast primitives. The cardano network works differently as it consists of pull-based, stateful protocols that can deal with network failures by design, i.e. clients need to ask and pull data from (uniform) upstream peers anyways. See the spike #1591 and this monthly report for more details why using |
|
I have sketched out both calls to And integrated the Replacing the call to |
github-project-automation
bot
moved this from In progress 🕐
to Done ✔
in ☕ Hydra Team Work
|
Re-open as not done yet |
This is a change I encountered when rebasing `raft-network` for #1720 and was useful back in the spike, but would have also been valuable in the `hydra-doom` use case. Anyways, this is adding a `--offline-head-seed` argument to offline mode and fixes the "simulation" opened head to be deterministic across multiple instances, resulting that the nodes can and do talk to each other and consequently sign snapshots. --- * [x] CHANGELOG updated * [x] Documentation updated * [x] Haddocks updated * [x] No new TODOs introduced
|
I will provide a "simple" interface to grapesy-etcd cardano-scaling/grapesy-etcd#3 |
Why
We saw in the recent spike #1591 that Raft (via etcd) provides benefits over our present approach: it allows for more instability in the client connections, and more transparency in what is happening.
We would like a resiliant and reliable networking layer, and this seems like a viable approach.
What
etcdcluster binaryetcdctlbinary to send client requests; use a Haskell (client) library insteadHow
raft-networkbranchPeerConnectedDisconnectedVersionMismatchversionkv and transactionsetcdctlclient with thegrapesygrpc client, see Create grapesy-etcd library #1843etcdHTTP APIHydra.Node.Network,Hydra.Network.OuroborosandHydra.Network.ReliabilitymodulesNodeIdfromConnected)snappy)Etcdcomponent works (and maps things toetcddomain)The text was updated successfully, but these errors were encountered: