search

libp2p / specs

Technical specifications for the libp2p networking stack
https://libp2p.io
1.56k stars 273 forks source link

Simple request/response #561

Open MarcoPolo opened 1 year ago

MarcoPolo commented 1 year ago

@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.

thomaseizinger commented 1 year ago

I'll review tomorrow.

thomaseizinger commented 1 year ago

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.

This is the first time I am hearing about such a thing as an explicitly optional spec. I thought that is the default?

MarcoPolo commented 1 year ago

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.