logos-messaging/logos-messaging-nim
1
0
Fork 0
mirror of https://github.com/logos-messaging/logos-messaging-nim.git synced 2026-01-31 12:13:10 +00:00
Code Issues Packages Projects Releases Wiki Activity
logos-messaging-nim/waku/api/send_api.md
NagyZoltanPeter 1fd25355e0
feat: waku api send (#3669) 
* 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

prepare for use in api_example

* Fix edge mode config and test added
* Fix some import issues, start and stop waku shall not throw exception but return with result properly
* Utlize sync RequestBroker, adapt to non-async broker usage and gcsafe where appropriate, removed leftover
* add api_example app to examples2
* Adapt after merge from master
* Adapt code for using broker context
* Fix brokerCtx settings for all usedbrokers, cover locked node init
* Various fixes upon test failures. Added initial of subscribe API and auto-subscribe for send api
* More test added
* Fix multi propagate event emit, fix fail send test case
* Fix rebase
* Fix PushMessageHandlers in tests
* adapt libwaku to api changes
* Fix relay test by adapting publish return error in case NoPeersToPublish
* Addressing all remaining review findings. Removed leftovers. Fixed loggings and typos
* Fix rln relay broker, missed brokerCtx
* Fix rest relay test failed, due to publish will fail if no peer avail
* ignore anvil test state file
* Make terst_wakunode_rln_relay broker context aware to fix
* Fix waku rln tests by having them broker context aware
* fix typo in test_app.nim
2026-01-30 01:06:00 +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 availabilities of peers.

Delivery task

Each message send request is bundled 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 whether 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
    • LightpushClient 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+simple retry -> Lightpush+StoreCheck -> Lightpush simple retry -> Error

Combination is dynamically 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.