waku-org
/
specs
mirror of https://github.com/waku-org/specs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

chore: use transport instead of relay

This commit is contained in:
kaichaosun 2024-07-04 09:52:53 +08:00
parent 7012292b63
commit 624c677009
No known key found for this signature in database
GPG Key ID: 223E0F992F4F03BF
1 changed files with 10 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
standards/application/relay-reliability.md
View File

@ -1,6 +1,6 @@
--- ---
title: RELIABILITY-RELAY title: TRANSPORT-RELIABILITY
name: Reliability for Relay Protocol name: Waku Transport Reliability
category: Standards Track category: Standards Track
tags: [reliability, application] tags: [reliability, application]
editor: Kaichao Sun <kaichao@status.im> editor: Kaichao Sun <kaichao@status.im>
@ -10,7 +10,7 @@ contributors:
## Abstract ## Abstract
[Relay Protocol](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) in Waku is efficient for routing messages, but there's no guarantee that a message will reach to its destination. For example, the receiver in a chat application may miss messages when network issue happens at either sender or receiver side. Waku is efficient for routing messages with its transport layer like [Relay Protocol](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) and [Lightpush](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md)/[Filter](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/12/filter.md), but there's no guarantee that a message going through Waku will reach to its destination. For example, the receiver in a chat application may miss messages when network issue happens at either sender or receiver side.
In general, a message in Waku network includes 3 status from sender's perspective: In general, a message in Waku network includes 3 status from sender's perspective:
@ -20,9 +20,9 @@ In general, a message in Waku network includes 3 status from sender's perspectiv
Application like Status already uses [MVDS](https://github.com/vacp2p/rfc-index/blob/main/vac/2/mvds.md) for e2e acknowledgement in direct messages and group chat. There is an ongoing [discussion](https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293) about a more general and bandwidth efficient solution for e2e reliablity. Application like Status already uses [MVDS](https://github.com/vacp2p/rfc-index/blob/main/vac/2/mvds.md) for e2e acknowledgement in direct messages and group chat. There is an ongoing [discussion](https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293) about a more general and bandwidth efficient solution for e2e reliablity.
In other words, an application defines a payload over Waku and is interested in e2e delivery between application users. Waku provides a pub/sub broadcast transport, which is interested in reliably routing a message to all participants in the pub/sub broadcast group. In other words, an application defines a payload over Waku and is interested in e2e delivery between application users. Waku provides a pub/sub broadcast transport, which is interested in reliably routing a message to all participants in the broadcast group.
Before we have a complete design for e2e reliability, we need to compose existing protocols to increase the reliability of the relay protocol. This document proposes a few options for such composition. The approch proposed here can also be applied to scenarios which depend on [Light Push](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md) and [Filter](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/12/filter.md) protocol, since they are service wrappers of Relay protocol. Before we have a complete design for e2e reliability, we need to compose existing protocols to increase the reliability of the transport protocol. This document proposes a few options for such composition.
## Motivation ## Motivation
@ -30,13 +30,13 @@ The [Store protocol](https://github.com/waku-org/specs/blob/master/standards/cor
**Search criteria with message hash** **Search criteria with message hash**
For the nodes that may have connection issues to **publish** messages via relay network, this search criteria can be used to check whether a message is populated in the network or not. The message exists in store node can be marked from `outgoing` to `sent` by application. If the message is not found in the store node, the application can resend the message. For the nodes that may have connection issues to **publish** messages via transport layer, this search criteria can be used to check whether a message is populated in the network or not. The message exists in store node can be marked from `outgoing` to `sent` by application. If the message is not found in the store node, the application can resend the message.
**Search criteria with topics and time range** **Search criteria with topics and time range**
For the nodes that may have connection issues to **receive** messages via relay network, this search criteria can be used to fetch missing messages from store nodes periodically after network resumes. For the nodes that may have connection issues to **receive** messages via transport layer, this search criteria can be used to fetch missing messages from store nodes periodically after network resumes.
In summary, by leveraging the store node to provide such query services, the applications are able to mitigate the reliability issue of relay protocol. In summary, by leveraging the store node to provide such query services, the applications are able to mitigate the reliability issue of transport layer.
But this approach also introduces new challenges like centralization, privacy, and scalability. It should be viewed as a temporary solution and deprecated when e2e reliability solution is ready. But this approach also introduces new challenges like centralization, privacy, and scalability. It should be viewed as a temporary solution and deprecated when e2e reliability solution is ready.
@ -157,7 +157,7 @@ When finishing fetching missing messages, the application should update the last
### Unified Query ### Unified Query
There are cases that both outgoing and incoming messages are queried in similar situation, for example at similar interval. The application can combine the above two worflows into one to have a unified query with better performance overall. There are cases that both outgoing and incoming messages are queried in similar situation, for example at same interval. The application can combine the above two worflows into one to have a unified query with better performance overall.
The workflow can be like this: The workflow can be like this:
- create outgoing buffer for all "outgoing" messages - create outgoing buffer for all "outgoing" messages
@ -165,6 +165,7 @@ The workflow can be like this:
- query store node based on topics and time range for message hashes periodically - query store node based on topics and time range for message hashes periodically
- check outgoing buffer with returned message hash, if included, mark message as `sent`, resend if needed. - check outgoing buffer with returned message hash, if included, mark message as `sent`, resend if needed.
- check incoming buffer with returned message hash, if not included, fetch the missing message with its hash. - check incoming buffer with returned message hash, if not included, fetch the missing message with its hash.
- update the last fetch time for the interested topic
## Security and Performance Considerations ## Security and Performance Considerations