Shrex client server specification #4665
Conversation
vgonkivs
requested review from
Wondertan,
gupadhyaya,
renaynay and
walldiss
as code owners
vgonkivs
changed the title
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## shrex_spec #4665 +/- ##
=============================================
Coverage ? 36.06%
=============================================
Files ? 304
Lines ? 20170
Branches ? 0
=============================================
Hits ? 7274
Misses ? 11944
Partials ? 952 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| - Retrieving data from local storage | ||
| - Sending responses back to clients | ||
|
|
||
| ### Request Handling |
There was a problem hiding this comment.
in certain cases (ND), not found comes with data too (non incl proof)
There was a problem hiding this comment.
Actually false. Server sends "OK" along with non-inclusion proof
specs/src/shrex/client-server.md
Outdated
| - **NOT FOUND**: Requested data is not available | ||
| - **INTERNAL ERROR**: Server encountered an error | ||
|
|
||
| 2. **Data (if OK)**: The actual requested data |
There was a problem hiding this comment.
also include non-incl proof if ND not found
specs/src/shrex/client-server.md
Outdated
|
|
||
| - Connection failures | ||
| - Timeouts | ||
| - Invalid data |
There was a problem hiding this comment.
meaning invalid data sent back from server?
walldiss
left a comment
walldiss
left a comment
There was a problem hiding this comment.
Needs to add:
- transport protocol spec (libp2p streaming)
- message flow. Status message definition and proto. Error model in status message
- reference to shwap spec defining encoding and payload of requests and responses
- peer manager integration, reference to peer manager spec
I haven't added this spec yet. My idea was to add it when I will be merging all specs into a single.
Client-Server does not interact with peer manager, but Getter does. I will update spec with Additionally, I can add a list of available endpoints |
| ### Request Messages | ||
|
|
||
| Request messages are binary encoded. | ||
|
|
||
| The request is serialized to binary format and written directly to the stream. Each request type includes: | ||
|
|
||
| - Height: Block height for the requested data | ||
| - Type-specific parameters |
There was a problem hiding this comment.
Requests use shwap id and associated encoding. We can be more specific here and link to the shwap spec
| ### Response Messages | ||
|
|
||
| #### Status Message | ||
|
|
||
| Every server response begins with a status message: | ||
|
|
||
| ```protobuf | ||
| enum Status { | ||
| INVALID = 0; // Invalid/unknown status | ||
| OK = 1; // Data found and will be sent | ||
| NOT_FOUND = 2; // Requested data not found | ||
| INTERNAL = 3; // Internal server error | ||
| } | ||
|
|
||
| message Response { | ||
| Status status = 1; | ||
| } | ||
| ``` |
There was a problem hiding this comment.
After handling requests server must send Status message indicating result of handling.
specs/src/shrex/client-server.md
Outdated
| ## Supported Endpoints | ||
|
|
||
| SHREX supports multiple endpoint types for retrieving different kinds of data. All endpoints follow the same request-response pattern but return different data structures. | ||
|
|
||
| ### Common Types | ||
|
|
||
| ```protobuf | ||
| message Share { | ||
| bytes data = 1; | ||
| } | ||
|
|
||
| enum AxisType { | ||
| ROW = 0; | ||
| COL = 1; | ||
| } | ||
| ``` | ||
|
|
There was a problem hiding this comment.
This should list shwap IDs and associated shawp.Containers. Encoding is defined in shwap spec, so no need to make copy of it here. But make sure to make to link them here. Formatting as table might look better:
| protocol-id | request (shwap.id) | response payload (shwap.container)
| - Retrieving data from local storage | ||
| - Sending responses back to clients | ||
|
|
||
| ### Request Handling |
There was a problem hiding this comment.
Actually false. Server sends "OK" along with non-inclusion proof
4 participants
Rendered