logos-messaging/logos-messaging-nim
1
0
Fork 0
mirror of https://github.com/logos-messaging/logos-messaging-nim.git synced 2026-01-03 22:43:09 +00:00
Code Issues Packages Projects Releases Wiki Activity
logos-messaging-nim/waku/api/send_api.md
NagyZoltanPeter 70c3afb4a7
Introduce api/send 
Added events and requests for support.
Reworked delivery_monitor into a featured devlivery_service, that
- supports relay publish and lightpush depending on configuration but with fallback options
- if available and configured it utilizes store api to confirm message delivery
- emits message delivery events accordingly

Notice: There are parts still in WIP and needs review and follow ups.

prepare for use in api_example
2025-12-14 06:33:14 +01:00

2.0 KiB
Raw Blame History

SEND API

THIS IS TO BE REMOVED BEFORE PR MERGE

This document collects logic and todo's around the Send API.

Overview

Send api hides the complex logic of using raw protocols for reliable message delivery. The delivery method is chosen based on the node configuration and actual availabilites of peers.

Delivery task

Each message send request is boundled into a task that not just holds the composed message but also the state of the delivery.

Delivery methods

Depending on the configuration and the availability of store client protocol + actual configured and/or discovered store nodes:

  • P2PReliability validation - checking network store node wheather the message is reached at least a store node.
  • Simple retry until message is propagated to the network
    • Relay says >0 peers as publish result
    • LightushClient returns with success

Depending on node config:

  • Relay
  • Lightpush

These methods are used in combination to achieve the best reliability. Fallback mechanism is used to switch between methods if the current one fails.

Relay+StoreCheck -> Relay+simeple retry -> Lightpush+StoreCheck -> Lightpush simple retry -> Error

Combination is dynamicly chosen on node configuration. Levels can be skipped depending on actual connectivity. Actual connectivity is checked:

  • Relay's topic health check - at least dLow peers in the mesh for the topic
  • Store nodes availability - at least one store service node is available in peer manager
  • Lightpush client availability - at least one lightpush service node is available in peer manager

Delivery processing

At every send request, each task is tried to be delivered right away. Any further retries and store check is done as a background task in a loop with predefined intervals. Each task is set for a maximum number of retries and/or maximum time to live.

In each round of store check and retry send tasks are selected based on their state. The state is updated based on the result of the delivery method.