Simple request/response #561
Conversation
|
I'll review tomorrow. |
This is the first time I am hearing about such a thing as an explicitly optional spec. I thought that is the default? |
Co-authored-by: Max Inden <[email protected]>
Co-authored-by: Max Inden <[email protected]>
MarcoPolo
force-pushed
the
marco/simple-req-resp
branch
from
d95cd25 to
1e1c96d
Compare
|
go-libp2p-kad-dht is compatible with this, despite it doing some pipelining. It tries to pipeline, but if that fails it will use a new stream. I think we should change the go-libp2p-kad-dht implementation to not pipeline. And I think this is still backwards compatible as existing clients will try a new stream if the server closes the stream or when the client fails to read the response for the pipelined request. |
|
|
||
| ## How to map to a libp2p stream | ||
|
|
||
| Each request and response should happen in a single stream. There SHOULD NOT be |
There was a problem hiding this comment.
| Each request and response should happen in a single stream. There SHOULD NOT be | |
| Each request and response should happen in a single stream. There MUST NOT be |
There was a problem hiding this comment.
For backwards compatibility, this can't be a MUST.
I'd like to have existing request/response over streams (like identify), to already be compliant with this spec.
There was a problem hiding this comment.
Previous discussion: #561 (comment)
| (signalling EOF to the peer). After handling the response, the client SHOULD | ||
| close the stream. After sending the response the server SHOULD close the stream |
There was a problem hiding this comment.
This sentence doesn't make sense, the client already closed the stream.
There was a problem hiding this comment.
Both sides can close the stream, right?
@mxinden / @thomaseizinger I believe this is what rust-libp2p does, could you confirm please?
The motivation for this PR is to introduce a way of defining request response style application protocols without requiring it to be built on top of HTTP semantics directly. This is meant to be minimal and very agnostic as to what the application protocol does. For example, I'm not defining a way to include metadata or headers here. This is to keep it minimal, but also to preserve backwards compatibility.
I'm open to naming suggestions for this instead of "simple request/response".
This is an optional spec in the sense that no implementation is required to implement an API for this, but when I talk about a simple request/response that can make use of all libp2p transports this is what I mean. It would be helpful to agree on that part.