2022-12-06 13:18:32 +11:00
|
|
|
import type { LightNode, RelayNode } from "@waku/interfaces";
|
2024-04-28 11:15:17 +02:00
|
|
|
import { Protocols } from "@waku/interfaces";
|
2024-08-31 15:18:51 +02:00
|
|
|
import { createRelayNode } from "@waku/relay";
|
2024-10-09 00:43:34 +02:00
|
|
|
import { createLightNode } from "@waku/sdk";
|
2025-07-19 17:19:58 +10:00
|
|
|
import { formatPubsubTopic } from "@waku/utils";
|
2022-07-25 12:33:08 +10:00
|
|
|
import { expect } from "chai";
|
|
|
|
|
|
2023-10-13 12:36:43 +03:00
|
|
|
import {
|
2024-02-15 08:50:03 +02:00
|
|
|
afterEachCustom,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
DefaultTestClusterId,
|
|
|
|
|
DefaultTestContentTopic,
|
|
|
|
|
DefaultTestNetworkConfig,
|
|
|
|
|
DefaultTestNumShardsInCluster,
|
|
|
|
|
DefaultTestRoutingInfo,
|
2023-10-13 12:36:43 +03:00
|
|
|
delay,
|
|
|
|
|
makeLogFileName,
|
|
|
|
|
NOISE_KEY_1,
|
2024-01-18 00:26:31 +05:30
|
|
|
ServiceNode,
|
2023-10-13 12:36:43 +03:00
|
|
|
tearDownNodes
|
|
|
|
|
} from "../src/index.js";
|
2022-07-25 12:33:08 +10:00
|
|
|
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
import { runRelayNodes } from "./relay/utils.js";
|
2024-04-28 11:15:17 +02:00
|
|
|
|
2022-07-25 12:33:08 +10:00
|
|
|
describe("Wait for remote peer", function () {
|
2022-12-06 13:18:32 +11:00
|
|
|
let waku1: RelayNode;
|
|
|
|
|
let waku2: LightNode;
|
2024-01-18 00:26:31 +05:30
|
|
|
let nwaku: ServiceNode;
|
2022-07-25 12:33:08 +10:00
|
|
|
|
2024-02-15 08:50:03 +02:00
|
|
|
afterEachCustom(this, async () => {
|
2023-10-13 12:36:43 +03:00
|
|
|
await tearDownNodes(nwaku, [waku1, waku2]);
|
2022-07-25 12:33:08 +10:00
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("Relay - dialed first", async function () {
|
|
|
|
|
this.timeout(20_000);
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
[nwaku, waku1] = await runRelayNodes(
|
|
|
|
|
this,
|
|
|
|
|
DefaultTestNetworkConfig,
|
|
|
|
|
undefined,
|
|
|
|
|
[DefaultTestContentTopic]
|
|
|
|
|
);
|
2022-07-25 12:33:08 +10:00
|
|
|
const multiAddrWithId = await nwaku.getMultiaddrWithId();
|
|
|
|
|
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
const peers = waku1.relay.getMeshPeers(DefaultTestRoutingInfo.pubsubTopic);
|
2022-07-25 12:33:08 +10:00
|
|
|
const nimPeerId = multiAddrWithId.getPeerId();
|
|
|
|
|
|
|
|
|
|
expect(nimPeerId).to.not.be.undefined;
|
|
|
|
|
expect(peers).to.includes(nimPeerId);
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("Relay - dialed after", async function () {
|
|
|
|
|
this.timeout(20_000);
|
2024-01-18 00:26:31 +05:30
|
|
|
nwaku = new ServiceNode(makeLogFileName(this));
|
2022-07-25 12:48:48 +10:00
|
|
|
await nwaku.start({
|
|
|
|
|
relay: true,
|
|
|
|
|
store: false,
|
|
|
|
|
filter: false,
|
2024-07-26 01:21:52 +03:00
|
|
|
lightpush: false,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
clusterId: DefaultTestClusterId,
|
|
|
|
|
numShardsInNetwork: DefaultTestNumShardsInCluster,
|
|
|
|
|
contentTopic: [DefaultTestContentTopic]
|
2022-07-25 12:48:48 +10:00
|
|
|
});
|
2022-07-25 12:33:08 +10:00
|
|
|
const multiAddrWithId = await nwaku.getMultiaddrWithId();
|
|
|
|
|
|
2022-12-06 13:18:32 +11:00
|
|
|
waku1 = await createRelayNode({
|
2024-07-26 01:21:52 +03:00
|
|
|
staticNoiseKey: NOISE_KEY_1,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
networkConfig: DefaultTestNetworkConfig,
|
|
|
|
|
routingInfos: [DefaultTestRoutingInfo]
|
2022-07-25 12:33:08 +10:00
|
|
|
});
|
2022-09-07 16:51:43 +10:00
|
|
|
await waku1.start();
|
2022-07-25 12:33:08 +10:00
|
|
|
|
2024-10-09 00:43:34 +02:00
|
|
|
const waitPromise = waku1.waitForPeers([Protocols.Relay]);
|
2022-07-25 12:33:08 +10:00
|
|
|
await delay(1000);
|
2022-09-07 16:51:43 +10:00
|
|
|
await waku1.dial(multiAddrWithId);
|
2022-07-25 12:33:08 +10:00
|
|
|
await waitPromise;
|
|
|
|
|
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
const peers = waku1.relay.getMeshPeers(DefaultTestRoutingInfo.pubsubTopic);
|
2022-07-25 12:33:08 +10:00
|
|
|
const nimPeerId = multiAddrWithId.getPeerId();
|
|
|
|
|
|
|
|
|
|
expect(nimPeerId).to.not.be.undefined;
|
|
|
|
|
expect(peers).includes(nimPeerId);
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("Relay - times out", function (done) {
|
|
|
|
|
this.timeout(5000);
|
2022-12-06 13:18:32 +11:00
|
|
|
createRelayNode({
|
2024-07-26 01:21:52 +03:00
|
|
|
staticNoiseKey: NOISE_KEY_1,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
networkConfig: DefaultTestNetworkConfig,
|
|
|
|
|
routingInfos: [DefaultTestRoutingInfo]
|
2022-07-25 12:33:08 +10:00
|
|
|
})
|
2022-09-07 16:51:43 +10:00
|
|
|
.then((waku1) => waku1.start().then(() => waku1))
|
|
|
|
|
.then((waku1) => {
|
2024-10-09 00:43:34 +02:00
|
|
|
waku1.waitForPeers([Protocols.Relay], 200).then(
|
2022-07-25 12:33:08 +10:00
|
|
|
() => {
|
|
|
|
|
throw "Promise expected to reject on time out";
|
|
|
|
|
},
|
|
|
|
|
(reason) => {
|
2024-10-09 00:43:34 +02:00
|
|
|
expect(reason?.message).to.eq(
|
|
|
|
|
"Timed out waiting for a remote peer."
|
|
|
|
|
);
|
2022-07-25 12:33:08 +10:00
|
|
|
done();
|
2023-08-16 20:18:13 +05:30
|
|
|
}
|
2022-07-25 12:33:08 +10:00
|
|
|
);
|
2023-07-24 16:04:24 +05:30
|
|
|
})
|
|
|
|
|
.catch((e) => done(e));
|
2022-07-25 12:33:08 +10:00
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("Store - dialed first", async function () {
|
|
|
|
|
this.timeout(20_000);
|
2024-01-18 00:26:31 +05:30
|
|
|
nwaku = new ServiceNode(makeLogFileName(this));
|
2022-07-25 12:48:48 +10:00
|
|
|
await nwaku.start({
|
|
|
|
|
store: true,
|
|
|
|
|
relay: false,
|
|
|
|
|
lightpush: false,
|
2023-08-16 20:18:13 +05:30
|
|
|
filter: false
|
2022-07-25 12:48:48 +10:00
|
|
|
});
|
2022-07-25 12:33:08 +10:00
|
|
|
const multiAddrWithId = await nwaku.getMultiaddrWithId();
|
|
|
|
|
|
2022-09-07 16:51:43 +10:00
|
|
|
waku2 = await createLightNode({
|
2024-07-26 01:21:52 +03:00
|
|
|
staticNoiseKey: NOISE_KEY_1,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
networkConfig: DefaultTestNetworkConfig
|
2022-07-25 12:33:08 +10:00
|
|
|
});
|
2022-09-07 16:51:43 +10:00
|
|
|
await waku2.start();
|
|
|
|
|
await waku2.dial(multiAddrWithId);
|
2022-07-25 12:33:08 +10:00
|
|
|
await delay(1000);
|
2024-10-09 00:43:34 +02:00
|
|
|
await waku2.waitForPeers([Protocols.Store]);
|
2022-07-25 12:33:08 +10:00
|
|
|
|
2025-01-31 00:16:00 +01:00
|
|
|
const peers = (await waku2.getConnectedPeers()).map((peer) =>
|
2024-01-19 20:42:52 +05:30
|
|
|
peer.id.toString()
|
|
|
|
|
);
|
2022-07-25 12:33:08 +10:00
|
|
|
const nimPeerId = multiAddrWithId.getPeerId();
|
|
|
|
|
|
|
|
|
|
expect(nimPeerId).to.not.be.undefined;
|
|
|
|
|
expect(peers.includes(nimPeerId as string)).to.be.true;
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("Store - dialed after - with timeout", async function () {
|
|
|
|
|
this.timeout(20_000);
|
2024-01-18 00:26:31 +05:30
|
|
|
nwaku = new ServiceNode(makeLogFileName(this));
|
2022-07-25 12:48:48 +10:00
|
|
|
await nwaku.start({
|
|
|
|
|
store: true,
|
|
|
|
|
relay: false,
|
|
|
|
|
lightpush: false,
|
2023-08-16 20:18:13 +05:30
|
|
|
filter: false
|
2022-07-25 12:48:48 +10:00
|
|
|
});
|
2022-07-25 12:33:08 +10:00
|
|
|
const multiAddrWithId = await nwaku.getMultiaddrWithId();
|
|
|
|
|
|
2022-09-07 16:51:43 +10:00
|
|
|
waku2 = await createLightNode({
|
2024-07-26 01:21:52 +03:00
|
|
|
staticNoiseKey: NOISE_KEY_1,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
networkConfig: DefaultTestNetworkConfig
|
2022-07-25 12:33:08 +10:00
|
|
|
});
|
2022-09-07 16:51:43 +10:00
|
|
|
await waku2.start();
|
2024-10-09 00:43:34 +02:00
|
|
|
const waitPromise = waku2.waitForPeers([Protocols.Store], 2000);
|
2022-07-25 12:33:08 +10:00
|
|
|
await delay(1000);
|
2022-09-07 16:51:43 +10:00
|
|
|
await waku2.dial(multiAddrWithId);
|
2022-07-25 12:33:08 +10:00
|
|
|
await waitPromise;
|
|
|
|
|
|
2025-01-31 00:16:00 +01:00
|
|
|
const peers = (await waku2.getConnectedPeers()).map((peer) =>
|
2024-01-19 20:42:52 +05:30
|
|
|
peer.id.toString()
|
|
|
|
|
);
|
2022-07-25 12:33:08 +10:00
|
|
|
|
|
|
|
|
const nimPeerId = multiAddrWithId.getPeerId();
|
|
|
|
|
|
|
|
|
|
expect(nimPeerId).to.not.be.undefined;
|
|
|
|
|
expect(peers.includes(nimPeerId as string)).to.be.true;
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("LightPush", async function () {
|
|
|
|
|
this.timeout(20_000);
|
2024-01-18 00:26:31 +05:30
|
|
|
nwaku = new ServiceNode(makeLogFileName(this));
|
2022-07-25 12:48:48 +10:00
|
|
|
await nwaku.start({
|
|
|
|
|
lightpush: true,
|
|
|
|
|
filter: false,
|
|
|
|
|
relay: false,
|
2023-08-16 20:18:13 +05:30
|
|
|
store: false
|
2022-07-25 12:48:48 +10:00
|
|
|
});
|
2022-07-25 12:33:08 +10:00
|
|
|
const multiAddrWithId = await nwaku.getMultiaddrWithId();
|
|
|
|
|
|
2022-09-07 16:51:43 +10:00
|
|
|
waku2 = await createLightNode({
|
2024-07-26 01:21:52 +03:00
|
|
|
staticNoiseKey: NOISE_KEY_1,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
networkConfig: DefaultTestNetworkConfig
|
2022-07-25 12:33:08 +10:00
|
|
|
});
|
2022-09-07 16:51:43 +10:00
|
|
|
await waku2.start();
|
|
|
|
|
await waku2.dial(multiAddrWithId);
|
2024-10-09 00:43:34 +02:00
|
|
|
await waku2.waitForPeers([Protocols.LightPush]);
|
2022-07-25 12:33:08 +10:00
|
|
|
|
2025-01-31 00:16:00 +01:00
|
|
|
const peers = (await waku2.getConnectedPeers()).map((peer) =>
|
|
|
|
|
peer.id.toString()
|
2022-07-25 12:33:08 +10:00
|
|
|
);
|
|
|
|
|
|
|
|
|
|
const nimPeerId = multiAddrWithId.getPeerId();
|
|
|
|
|
|
|
|
|
|
expect(nimPeerId).to.not.be.undefined;
|
|
|
|
|
expect(peers.includes(nimPeerId as string)).to.be.true;
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("Filter", async function () {
|
|
|
|
|
this.timeout(20_000);
|
2024-01-18 00:26:31 +05:30
|
|
|
nwaku = new ServiceNode(makeLogFileName(this));
|
2022-07-25 12:48:48 +10:00
|
|
|
await nwaku.start({
|
|
|
|
|
filter: true,
|
|
|
|
|
lightpush: false,
|
|
|
|
|
relay: false,
|
2023-08-16 20:18:13 +05:30
|
|
|
store: false
|
2022-07-25 12:48:48 +10:00
|
|
|
});
|
2022-07-25 12:33:08 +10:00
|
|
|
const multiAddrWithId = await nwaku.getMultiaddrWithId();
|
|
|
|
|
|
2022-09-07 16:51:43 +10:00
|
|
|
waku2 = await createLightNode({
|
2024-07-26 01:21:52 +03:00
|
|
|
staticNoiseKey: NOISE_KEY_1,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
networkConfig: DefaultTestNetworkConfig
|
2022-07-25 12:33:08 +10:00
|
|
|
});
|
2022-09-07 16:51:43 +10:00
|
|
|
await waku2.start();
|
|
|
|
|
await waku2.dial(multiAddrWithId);
|
2024-10-09 00:43:34 +02:00
|
|
|
await waku2.waitForPeers([Protocols.Filter]);
|
2022-07-25 12:33:08 +10:00
|
|
|
|
2025-01-31 00:16:00 +01:00
|
|
|
const peers = (await waku2.getConnectedPeers()).map((peer) =>
|
2023-08-16 20:18:13 +05:30
|
|
|
peer.id.toString()
|
2022-09-07 16:51:43 +10:00
|
|
|
);
|
|
|
|
|
|
|
|
|
|
const nimPeerId = multiAddrWithId.getPeerId();
|
|
|
|
|
|
|
|
|
|
expect(nimPeerId).to.not.be.undefined;
|
|
|
|
|
expect(peers.includes(nimPeerId as string)).to.be.true;
|
|
|
|
|
});
|
|
|
|
|
|
2025-01-31 00:16:00 +01:00
|
|
|
// TODO: re-enable store once https://github.com/waku-org/js-waku/issues/2162 is fixed
|
2022-09-07 16:51:43 +10:00
|
|
|
it("Light Node - default protocols", async function () {
|
|
|
|
|
this.timeout(20_000);
|
2024-01-18 00:26:31 +05:30
|
|
|
nwaku = new ServiceNode(makeLogFileName(this));
|
2022-09-07 16:51:43 +10:00
|
|
|
await nwaku.start({
|
|
|
|
|
filter: true,
|
|
|
|
|
lightpush: true,
|
2025-01-31 00:16:00 +01:00
|
|
|
relay: false
|
|
|
|
|
// store: true
|
2022-09-07 16:51:43 +10:00
|
|
|
});
|
|
|
|
|
const multiAddrWithId = await nwaku.getMultiaddrWithId();
|
|
|
|
|
|
|
|
|
|
waku2 = await createLightNode({
|
2024-07-26 01:21:52 +03:00
|
|
|
staticNoiseKey: NOISE_KEY_1,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
networkConfig: DefaultTestNetworkConfig
|
2022-09-07 16:51:43 +10:00
|
|
|
});
|
|
|
|
|
await waku2.start();
|
|
|
|
|
await waku2.dial(multiAddrWithId);
|
2024-10-09 00:43:34 +02:00
|
|
|
await waku2.waitForPeers([
|
2022-12-07 11:35:30 +05:30
|
|
|
Protocols.Filter,
|
2025-01-31 00:16:00 +01:00
|
|
|
// Protocols.Store,
|
2023-08-16 20:18:13 +05:30
|
|
|
Protocols.LightPush
|
2022-12-07 11:35:30 +05:30
|
|
|
]);
|
2022-09-07 16:51:43 +10:00
|
|
|
|
2025-01-31 00:16:00 +01:00
|
|
|
const peers = (await waku2.getConnectedPeers()).map((peer) =>
|
|
|
|
|
peer.id.toString()
|
2022-09-07 16:51:43 +10:00
|
|
|
);
|
|
|
|
|
|
|
|
|
|
const nimPeerId = multiAddrWithId.getPeerId();
|
|
|
|
|
|
|
|
|
|
expect(nimPeerId).to.not.be.undefined;
|
2025-01-31 00:16:00 +01:00
|
|
|
expect(peers.includes(nimPeerId as string)).to.be.true;
|
2022-09-07 16:51:43 +10:00
|
|
|
});
|
|
|
|
|
|
2025-07-19 17:19:58 +10:00
|
|
|
it("Relay Node - default protocol", async function () {
|
2022-09-07 16:51:43 +10:00
|
|
|
this.timeout(20_000);
|
2025-07-19 17:19:58 +10:00
|
|
|
[nwaku, waku1] = await runRelayNodes(this, { clusterId: 0 }, [0]);
|
2022-09-07 16:51:43 +10:00
|
|
|
const multiAddrWithId = await nwaku.getMultiaddrWithId();
|
|
|
|
|
|
2025-07-19 17:19:58 +10:00
|
|
|
const peers = waku1.relay.getMeshPeers(formatPubsubTopic(0, 0));
|
2022-07-25 12:33:08 +10:00
|
|
|
|
|
|
|
|
const nimPeerId = multiAddrWithId.getPeerId();
|
|
|
|
|
|
|
|
|
|
expect(nimPeerId).to.not.be.undefined;
|
|
|
|
|
expect(peers.includes(nimPeerId as string)).to.be.true;
|
|
|
|
|
});
|
|
|
|
|
});
|