-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace networking stack with etcd-based approach #1720
Comments
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 |
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
etcd
cluster binaryetcdctl
binary to send client requests; use a Haskell (client) library insteadHow
raft-network
branchPeerConnected
etcdctl
client with thegrapesy
grpc client, see Create grapesy-etcd library #1843etcd
HTTP APIHydra.Node.Network
,Hydra.Network.Ouroboros
andHydra.Network.Reliability
modulesThe text was updated successfully, but these errors were encountered: