Skip to main content

45 posts tagged with "network"

View All Tags

· 2 min read
Marcin Szamotulski

Overview of sprint 77​

Initiator only mode for local roots​

We implemented the initiator-only mode for local roots peers described in ouroboros-network#5020. This feature will be available in cardano-node-10.3 (cardano-node#6055).

One will be able to specify diffusionMode (either InitiatorOnly or IntiatorAndRespoinder, the latter is the default) for all local roots in a given local roots group, e.g.

{ "localRoots":
    [ { "accessPoints":
          [ { "address": "10.0.0.1"
            , "port": 3001
            }
          ]
      , "advertise": false
      , "diffusionMode": "InitiatorOnly"
      , "warmValency": 1
      , "hotValency": 1
      }
    , { "accessPoints":
          [ { "address": "10.0.0.2"
            , "port": 3001
            }
          ]
      , "advertise": true
      , "diffusionMode": "InititiatorAndResponder"
      , "warmValency": 1
      , "hotValency": 1
      }
    ]
, "publicRoots": []
, "useLedgerAfterSlot": -1
}

As part of ouroboros-network#5020 we had to change how connections are identified in the simulated testnet environment. We exposed ConnStateIdSupply through P2P interfaces, which allows us to use a global ConnStateIdSupply for all nodes in the simulation. This way, ConnStateId is unique for each connection in the simulation. See ouroboros-network#5026.

Support systems with multiple IP addresses​

We merged ouroboros-network#5017 which allows to run cardano-node on systems with multiple network interfaces or a single interface with multiple IP addresses.

Reusable diffusion​

We were working on early integration of reusable diffusion work stream with ouroboros-consensus & cardano-node. Reusable diffusion will allow us to support both cardano-node and mithril-node in the future. We are pleased to say that we are running a cardano-node that uses refactored diffusion. See:

Tx-Submission Logic​

We had a discussion with the consensus team (Karl Knutsson CF, Nick Frisby Tweag) on network requirements for tx-mempool. See:

SRV record support​

We continued working on the SRV support, see:

Technical Debt​

We renamed some of the test modules to be more consistent across various network components, see ouroboros-network#5028.

· 3 min read
Marcin Szamotulski

Overview of sprint 76​

Network Load​

The Cardano Foundation monitors the network by injecting "canary" transactions, allowing us to measure the time taken for a transaction to be included in a block. Approximately four to five of these transactions are submitted every hour.

Since early November, network load has increased, but most transactions are still included within the first or second block after submission. Even if the network is not congested, transactions may not reach the Block Producer responsible for the next block in time due to network propagation delays. Therefore, only a transaction that takes three or more blocks to be included indicates a loaded network.

Since November 1, 2024, we have submitted around 3,700 "canary" transactions, and only 59 of them took longer than two blocks to be included, meaning 98.4% of our test transactions were included within the two-block limit. During this period, the longest observed time to inclusion was five blocks for two transactions and the maximum wait time is 201 seconds.

Network Load

Where the y-axis is a fraction of the block size in the respected dimension (e.g. size, steps, memory).

Hot Standby Block-Producer Nodes​

In the last Network Working Group Meeting (NWG) we discussed solutions for running hot standby block producers using P2P.

Short-Term Solution: Local Root Initiator Only Outbound Connections​

We agreed to implement initiator-only connections for local roots, which wouldn't bind to the node address (and thus would be made from an ephemeral port). This allows SPOs to have hot standby nodes which are hidden from relays using a firewall rule, while they still can connect to the relays (so they receive blocks while the blocks they produce are not sent to the network). See the ouroboros-network#5020 issue and associated PRs:

The latter PR makes P2P node run on systems with multiple network interfaces or a single interface with multiple IP addresses.

An SPO can control the diffusion mode (initiator only / initiator and responder) in the topology file. A draft PR is available in the coot/connection-manager-initiator-only-0.13.2.5 branch.

In the NWG meeting, it was agreed that once this functionality is implemented, we can remove NonP2P code from ouroboros-network (ouroboros-network#5007).

Long-Term Solution​

An agreed long-term solution is to allow to control block propagation of self-produced blocks through cardano-cli.

Reusable Diffusion​

We continued working on making ouroboros-network reusable for both cardano-node and mithril (see CIP#137). The PR can be found here: ouroboros-network#5016, while a more detailed description of its direction can be found here. During this sprint, we carried out a team-wise PR review.

Block Fetch Client For Genesis​

A new block-fetch client designed for Genesis was merged, see ouroboros-network#4919. The design of the new block-fetch Gensis logic is described in here.

KES Agent: Raw Bearer API​

We recently merged ouroboros-network#4395 - a PR which is important for the KES-agent workstream.

· 2 min read
Marcin Szamotulski

Overview of sprint 74​

Dropping NonP2P network stack​

We are advertising that we will drop the non-p2p network stack. This will happen after the next hard fork. Please comment on the PR if this will be problematic for you. Here's the PR: ouroboros-network#5007.

Node-to-Client versions​

We dropped node-to-client versions earlier than version 16, ouroboros-network#5002.

Mithril Design​

We completed review how to adopt ouroboros-network for Mithril design. We started to experiment with ouroboros-network in that direction.

Next Cardano-Node release​

The next cardano-node release will include the following changes from the networking team:

Typed-Protocols​

The integration of ouroboros-network-0.18, which is using the new typed-protocols-0.3 with ouroboros-consensus, was merged, ouroboros-consensus#1223. Integration with cardano-cli and cardano-api was rebased and handed to the release engineer. Integration with ekg-forward was merged: ekg-forward#35.

Genesis​

The following changes to support Genesis (both creating big ledger peer snapshots & providing them in a topology file)

Connection Manager​

We merged the documentation review of the connection manager, ouroboros-network#5001. We also renamed connection manager methods (as suggested by Neil Davies ([PNSOL])): ouroboros-network#5000.

Outbound Governor​

We started to experiment with using FRP to implement the outbound governor in a way that is both easier to maintain and reason about.

· One min read
Marcin Szamotulski

Overview of sprint 73​

Ouroboros-Network-0.18 release​

We released ouroboros-network-0.18. The main features are:

  • integration with typed-protocols-0.3
  • cardano-client library doesn't depend on the non-p2p stack
  • We expose connectToWithMux family of function in ouroboros-network which give access to the underlying Mux handle.
  • Added NodeToClientV_19: to support new GetLedgerPeerSnapshot query in local-state-query mini-protocol ouroboros-consensus#1067.

See full the list of PRs included in this release. ouroboros-network-0.18 was integrated with ouroboros-consensus (ouroboros-consensus#1223)

Tx-Submission​

We continued working on tx-submission monitoring its performance.

Ouroboros-Network - Mithril Design​

We had an internal discussion how to support the Mithril design. In near future we will be able to socialise the report we've been working on.

Code Refactoring​

We reorganised some of our substysems to use qualified imports with simplified names:

We also removed deprecated APIs in [ouroboros-network#4998]

· One min read
Marcin Szamotulski

Overview of [sprint 73][sprint-73]​

Ouroboros-Network-0.18 release​

We released ouroboros-network-0.18. The main features are:

  • integration with typed-protocols-0.3
  • cardano-client library doesn't depend on the non-p2p stack
  • We expose connectToWithMux family of functions in ouroboros-network which give access to the underlying [Mux handle][mux-handle].
  • Added NodeToClientV_19: to support the new GetLedgerPeerSnapshot query in local-state-query mini-protocol [ouroboros-consensus#1067].

See full [the list of PRs][ouroboros-network-0.18] included in this release. ouroboros-network-0.18 was integrated with ouroboros-consensus ([ouroboros-consensus#1223])

Tx-Submission​

We continued working on tx-submission and monitoring its performance.

Ouroboros-Network - Mithril Design​

We internally discussed how to support the [Mithril design][cip#137]. In In the near future, we will be able to socialise the report we've been working on.

Code Refactoring​

We reorganised some of our substysems to use qualified imports with simplified names:

  • [ouroboros-network#4990] (connection-manager, inbound-governor)
  • [ouroboros-network#4997] (network-mux)

We also removed deprecated APIs in [ouroboros-network#4998]sim#182]