tests(proto): fix description of how ManyToMany routing works

[flub]

Description

The routing description didn't match the code.

Breaking Changes

none

Notes & open questions

n/a

Change checklist

• Self-review.

[github-actions]

Documentation for this PR has been generated and is available at: https://n0-computer.github.io/noq/pr/726/docs/noq/

Last updated: 2026-07-01T15:50:32Z

[github-actions]

Performance Comparison Report

cea3d800729df5d4302bf021e70a8ad4366f6c21 - artifacts

Raw Benchmarks (localhost)

Scenario	noq	upstream	Delta	CPU (avg/max)
large-single	5294.0 Mbps	7894.3 Mbps	-32.9%	94.0% / 100.0%
medium-concurrent	5324.3 Mbps	7913.0 Mbps	-32.7%	93.7% / 98.0%
medium-single	4042.6 Mbps	4691.6 Mbps	-13.8%	94.1% / 101.0%
small-concurrent	3814.7 Mbps	5222.9 Mbps	-27.0%	99.4% / 153.0%
small-single	3427.5 Mbps	4713.7 Mbps	-27.3%	89.4% / 97.3%

Netsim Benchmarks (network simulation)

Condition	noq	upstream	Delta
ideal	3012.6 Mbps	4027.4 Mbps	-25.2%
lan	782.4 Mbps	796.4 Mbps	-1.8%
lossy	69.8 Mbps	69.8 Mbps	~0%
wan	83.8 Mbps	83.8 Mbps	~0%

Summary

noq is 27.0% slower on average

---

7d530bfc12bad38b5a39f8b752d62b89ba754519 - artifacts

No results available

---

54775e81e02f0ed6ef8191e0e4c076f457da9e7f - artifacts

Raw Benchmarks (localhost)

Scenario	noq	upstream	Delta	CPU (avg/max)
large-single	5307.4 Mbps	7499.3 Mbps	-29.2%	93.1% / 98.0%
medium-concurrent	5286.4 Mbps	8011.8 Mbps	-34.0%	94.8% / 146.0%
medium-single	3583.1 Mbps	4540.7 Mbps	-21.1%	93.6% / 101.0%
small-concurrent	3735.6 Mbps	5244.1 Mbps	-28.8%	100.9% / 153.0%
small-single	3461.2 Mbps	4507.4 Mbps	-23.2%	98.1% / 150.0%

Netsim Benchmarks (network simulation)

Condition	noq	upstream	Delta
ideal	3054.4 Mbps	N/A	N/A
lan	782.4 Mbps	N/A	N/A
lossy	55.9 Mbps	N/A	N/A
wan	83.8 Mbps	N/A	N/A

Summary

noq is 28.3% slower on average

---

08d4d0a2eb3651a55849d0f85aeb9c287c6674a8 - artifacts

Netsim Benchmarks (network simulation)

Condition	noq	upstream	Delta
ideal	N/A	4019.3 Mbps	N/A

---

5ad1e45c3acdd63b5e9a9d3a640cf7acc5c1578f - artifacts

Raw Benchmarks (localhost)

Scenario	noq	upstream	Delta	CPU (avg/max)
large-single	5488.9 Mbps	7991.6 Mbps	-31.3%	93.8% / 98.2%
medium-concurrent	5260.2 Mbps	7799.0 Mbps	-32.6%	96.1% / 148.0%
medium-single	3813.2 Mbps	4631.7 Mbps	-17.7%	95.3% / 148.0%
small-concurrent	3680.7 Mbps	5188.4 Mbps	-29.1%	91.8% / 101.0%
small-single	3381.1 Mbps	4743.4 Mbps	-28.7%	91.7% / 102.0%

Netsim Benchmarks (network simulation)

Condition	noq	upstream	Delta
ideal	3017.9 Mbps	3960.4 Mbps	-23.8%
lan	782.4 Mbps	810.3 Mbps	-3.4%
lossy	69.8 Mbps	69.9 Mbps	~0%
wan	83.8 Mbps	83.8 Mbps	~0%

Summary

noq is 27.5% slower on average

[matheus23]

I think there was a misunderstanding what the usize in each _routes array was meant to be for a long time now.

My old interpretation was: If there is e.g. a server_routes entry (2.2.2.1, 0) that means "You can send to the server at address 2.2.2.1, and then the 0 helps to identify which address the server will see as "remote". I.e. it's the client interface that will be used for the server address 2.2.2.1.

It seems like we merged a doc comment for ManyToManyRouting that contradicts this fact. It assumes that the index in the tuple is for outgoing connections, not incoming ones.

The rest of the code does not work this way! Even if we switch to the "other" interpretation of ManyToManyRouting, then ManyToManyRouting::add_client_route and add_server_route would need to be changed as well.

Instead, I'd appreciate if we could just fix the doc comment on ManyToManyRouting and keep the old interpretation. The rest of the code assumes the old interpretation.

[flub]

PTAL, maybe one day I'll understand this 😢

[matheus23]

Looks good. But please update the PR description!

(And a small nit about mentioning src_ip as a caveat)

[matheus23]

It does allow creating links are not functional in both directions however by using a dummy or mismatching for the allowed incoming source addresses.

Yeah this is true, if src_ip is set. Perhaps it's worth elaborating on that with this fact.

I.e. an example would be (pseudocode):

let routes = ManyToManyRouting {
  client_routes: [(1.1.1.1, 1), (1.1.1.2, 1)],
  server_routes: [(2.2.2.1, 1), (2.2.2.2, 1)],
}

This would be a routing setup where the client can send to 2.2.2.1, but only if it uses src_ip = 1.1.1.2, and the server can send to the client's 1.1.1.1, but only if it uses src_ip = 2.2.2.2.

But that means that if the client starts sending to 2.2.2.1 with src_ip = None, it will use 1.1.1.2, and then when the server answers to 1.1.1.2, it will use src_ip = Some(2.2.2.1), which doesn't match 2.2.2.2 so is discarded.

I think I've seen this behavior generate proptest failures in the past? But IMO this shouldn't generate proptest failures. This could be a buggy network or operating system, and we should basically assume that once we send stuff into the internet, that network might be programmed for anything to happen.

[flub]

updated to include an example (which is actually what i wanted to do and the whole reason i was poking at this again). also removed the claim you can use a dummy interface since ::new forbids you to refer to an unknown interface even though the routing code deals fine with it.

[matheus23]

Please still fix the PR description and title :)