-
Notifications
You must be signed in to change notification settings - Fork 208
Open
Description
Description
Proposed work
Add a generic request/response layer that:
- opens a fresh substream per request
- uses length-prefixed framing
- enforces bounded request/response sizes by default
- enforces a request timeout by default
- owns close/reset behavior internally
- supports pluggable codecs without forcing one serialization format
Public API
Add a new libp2p.request_response package exposing:
RequestResponseRequestResponseConfigRequestContextRequestResponseCodecBytesCodecJSONCodec- typed request/response exceptions
Initial scope
- one request
- one response
- one substream
- no retries
- no request IDs
- no streaming responses
- no protocol-specific or Filecoin-specific behavior
Validation goals
- unit tests for framing and codecs
- integration tests over real hosts
- example demonstrating a listener and dialer round trip
- docs for API and example usage
Acceptance criteria
- callers can register a handler for a protocol and send one request to a peer
- default limits and timeout are enforced
- malformed payloads and handler failures fail safely
- protocol negotiation failures are translated into typed helper errors
- docs and example are included
Motivation
Add a new libp2p.request_response helper that provides a safe, one-shot request/response API on top of libp2p streams.
Current Implementation
Today, applications that want a simple request/response pattern on top of py-libp2p have to build it manually on raw streams. That requires every caller to reimplement:
- framing
- timeouts
- payload size limits
- close vs reset behavior
- encode/decode error handling
This is easy to get wrong and leads to inconsistent security and reliability across applications.
Are you planning to do it yourself in a pull request ?
Yes
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels