logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-01-05 23:53:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #39 from waku-org/chore-enhance-peerexchange-status-response

Browse Source 
chore: Adjusted peer-exchange to the latest changes made due to rate limit DOS protection
This commit is contained in:
NagyZoltanPeter 2024-09-18 14:43:23 +02:00 committed by GitHub
commit af8c261f24
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 20 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
standards/core/peer-exchange.md
View File

@ -66,16 +66,18 @@ message PeerInfo {
bytes enr = 1; bytes enr = 1;
} }
message PeerExchangeQuery { message PeerExchangeRequest {
uint64 num_peers = 1; uint64 num_peers = 1;
} }
message PeerExchangeResponse { message PeerExchangeResponse {
repeated PeerInfo peer_infos = 1; repeated PeerInfo peer_infos = 1;
uint32 status_code = 10;
optional string status_desc = 11;
} }
message PeerExchangeRPC { message PeerExchangeRPC {
PeerExchangeQuery query = 1; PeerExchangeRequest request = 1;
PeerExchangeResponse response = 2; PeerExchangeResponse response = 2;
} }
@ -83,9 +85,22 @@ message PeerExchangeRPC {
The `enr` field contains a Waku ENR as specified in [WAKU2-ENR](./enr.md). The `enr` field contains a Waku ENR as specified in [WAKU2-ENR](./enr.md).
Requesters send a `PeerExchangeQuery` to a peer. Requesters send a `PeerExchangeRequest` to a peer.
Responders SHOULD include a maximum of `num_peers` `PeerInfo` instances into a response. Responders SHOULD include a maximum of `num_peers` `PeerInfo` instances into a response.
Responders send a `PeerExchangeResponse` to requesters containing a list of `PeerInfo` instances, which in turn hold an ENR. Responders send a `PeerExchangeResponse` to requesters containing a list of `PeerInfo` instances, which in turn hold an ENR.
Responders, MUST include a `status_code` in the response.
They MAY include a descriptive status in the `status_desc` field if available.
### Possible status codes
| Result | Code | Note |
|--------|------|------|
| SUCCESS | 200 | Successful request-response. |
| BAD_REQUEST | 400 | Wrong request payload. It must only contain `request` field. |
| BAD_RESPONSE | 401 | Malformed or illegal response payload returned. If success it must contain `response` and `status_code` fields. If failure, only `status_code` is set. |
| TOO_MANY_REQUESTS | 429 | DOS protection prevented this request as the current request exceeds the configured request rate. |
| SERVICE_UNAVAILABLE | 503 | Request cannot be performed on requester (client) side, either issue on Responder side or having no suitable peer to issue request. |
| DIAL_FAILURE | 599 | Requester (client) side problem calling PeerExchange peer. |
## Implementation Suggestions ## Implementation Suggestions
@ -143,6 +158,8 @@ Requesters send a simple message request which causes responders to engage in am
As a mitigation, responders MAY feature a `seen cache` for requests and only answer once per time interval. As a mitigation, responders MAY feature a `seen cache` for requests and only answer once per time interval.
The exchange-peer cache discussed in [Theory and Protocol Semantics Section](#theory-and-protocol-semantics) also provides mitigation. The exchange-peer cache discussed in [Theory and Protocol Semantics Section](#theory-and-protocol-semantics) also provides mitigation.
Still, frequent queries can tigger the refresh cycle more often. The `seen cache` MAY be used in conjunction to provide additional mitigation. Still, frequent queries can tigger the refresh cycle more often. The `seen cache` MAY be used in conjunction to provide additional mitigation.
Responders MAY apply request limits and thus can reject answering requests within a certain time window.
Requesters must be prepared to handle this case.
### Further Considerations ### Further Considerations