Rendezvous Peer Discovery – Test Cases and Next Steps

[seetadev]

Hi @sumanjeet0012,

I spent some time digging deeper into where the Rendezvous peer discovery module fits best, and I wanted to share some notes + recommendations before we finalize the PR.

---

When is Rendezvous Discovery Useful?

Rendezvous peer discovery shines in scenarios where:

• Peers need to dynamically discover each other without a static bootstrap list.
• Services are organized by namespaces or topics (e.g., /chat/v1, /file-share/test).
• The network is ad-hoc or frequently changing, such as mobile peers, browser clients, or applications where nodes come online/offline often.
• We want a lighter alternative to DHT lookups for small to mid-size networks.

In practice, peers:

1. Register themselves at a rendezvous server under a given namespace.
2. Other peers query the server to discover registered peers for that namespace.

This is extremely useful in application-level overlays (chat, collaborative tools, service directories) where direct peer bootstrapping is hard to manage.

---

Suggested Test Case to Add

To ensure correctness and interoperability, I recommend adding at least one end-to-end test that covers the following flow:

1. Start a Rendezvous server node.
2. Create two peers (peer1, peer2).
3. Connect both peers to the server.
4. peer1 registers under a namespace (say "test-namespace").
5. peer2 queries the rendezvous server for the same namespace.
6. Verify that peer2 receives peer1 in the discovery results.

Pseudo-code outline (Python-style):

# 1. Setup rendezvous server
# 2. Setup peer1 + peer2
# 3. Peer1 registers under "test-namespace"
# 4. Peer2 discovers peers under "test-namespace"
# 5. Assert: discovery results contain peer1

This test ensures that the module works as expected and gives us confidence before merging.

---

Possible Extensions (for later)

Once the base test is in place, we could also explore:

• Multiple namespaces (peer1 in /chat, peer2 in /files)
• Expired registrations (TTL handling)
• No peers registered → query should return empty
• Scale tests (register N peers, discover all)

---

Next Step

We are very close to merging this PR 🎉.
Would you be able to add a basic registration + discovery test case before we finalize?

This will:

• Document the expected behavior in code.
• Prevent regressions in the future.
• Make the module easier to adopt by new contributors.

Thanks again for the great work pushing this forward.

CCing @pacrob in this discussion thread. Thank you Paul for your continued guidance and support.

[sumanjeet0012]

Current Test Coverage

@seetadev Thank you for the detailed testing suggestions! Here's an overview of what test scenarios are already implemented in the current rendezvous PR and what could be added for even better coverage.

✅ Multiple namespaces (peer1 in /chat, peer2 in /files)

• test_rendezvous_multiple_namespaces() - Tests different peers in different namespaces

✅ Expired registrations (TTL handling)

• test_get_valid_peers_expired() - Tests peer cache expiration
• test_cleanup_expired_registrations() - Service-level cleanup of expired registrations

✅ No peers registered → query should return empty

• test_empty_discovery_result() - Tests discovery when no peers registered
• test_handle_discover_no_peers() - Service-level empty namespace test

⚠️ Scale tests (register N peers, discover all)

• test_discovery_with_limit() - Tests with limited result sets (mocked)
• test_concurrent_operations() - Tests 3 concurrent operations
• Missing: True large-scale test with 50+ actual peer registrations

The core scenarios are covered, but large-scale testing (100+ peers) could be enhanced.

[seetadev]

@sumanjeet0012 : Great, thank you so much for sharing. Appreciate it.

We will try and get server access to conduct tests at scale.

Will update you as soon as I hear back from friends & collaborators.