logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-01-04 07:03:14 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fixed message structure upon review agreement in order to keep backward compatibility with the former protocol format

Browse Source
This commit is contained in:
NagyZoltanPeter 2024-09-16 11:59:27 +02:00
parent 4c7515d632
commit 90efdfa6af
No known key found for this signature in database
GPG Key ID: 16EADB9673B65368
1 changed files with 5 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -72,17 +72,13 @@ message PeerExchangeRequest {
message PeerExchangeResponse {
repeated PeerInfo peer_infos = 1;
}
message PeerExchangeResponseStatus {
uint32 status = 1;
optional string desc = 2;
uint32 status = 10;
optional string desc = 11;
}
message PeerExchangeRPC {
optional PeerExchangeRequest request = 1;
optional PeerExchangeResponse response = 2;
optional PeerExchangeResponseStatus response_status = 10;
PeerExchangeRequest request = 1;
PeerExchangeResponse response = 2;
}
```
@ -90,10 +86,9 @@ message PeerExchangeRPC {
The `enr` field contains a Waku ENR as specified in [WAKU2-ENR](./enr.md).
Requesters send a `PeerExchangeRequest` to a peer.
Responders SHOULD not fill `request` field.
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, MUST include a `PeerExchangeResponseStatus` in the response in any case. If the request was not successful `response` field can be omitted.
Responders, MUST include a `status` in the response in any case and possible descriptive form of the problem if any.
### Possible status codes