For a peer-to-peer application, the nodes should be able to establish a connection and communicate. The communication will take place in the form of requests which would be answered with a response. This sounds very much like HTTP. Unfortunately, in HTTP, only the client can initiate a request. In this P2P system, the communication flow is symmetric. Both sides can ask each other questions. Multiple such requests can be outstanding at the same time.

Is there a well-known protocol that can be used to implement such a flow of information?

I thought about WebSockets but they are, as I understand it, not request/response based. They are an uncorrelated stream of messages in both directions. This means that requests and responses would not be matched.

It would be possible to open 2 HTTP channels but that is generally not feasible because not all nodes can open a port through their router.

Ideally, we would have bidirectional HTTP2 but, I believe, this does not exist.

CodePudding user response：

Maybe gRPC can help you.

In gRPC, a client application can directly call a method on a server application on a different machine as if it were a local object, making it easier for you to create distributed applications and services.

CodePudding user response：

QUIC is the basis of HTTP3. QUIC can be used independently of HTTP, though. It seems to provide the semantics that are desired.

Both sides can create streams over a QUIC connection. A request/response transaction could be implemented as a new stream that is written to only once by both sides, and then closed. QUIC makes this efficiently possible (after all, this is what HTTP3 does).

QUIC has many advantages. It is very efficient, does not suffer from head-of-line blocking, has web-grade security built-in, it has a fast handshake and it can migrate connections between IP addresses.

The connection model of QUIC is described here rather well.

The WebTransport standard aims to expose QUIC to browsers through JavaScript. As far as I can tell, WebTransport can therefore be used as well. Although it seems to be an unnecessary protocol layer for the application described in the question. On the other hand, it would allow browsers to participate in the peer-to-peer network as well.

An entirely different solution would be to use long polling ("comet") over any HTTP version. The client can issue requests to the server directly. In addition, the client would always keep one long-polling request to the server outstanding, thereby asking the server if the server wishes to send a request itself.

WebSockets could be used if requests and responses are matched up manually by the application. This manual implementation work is precisely what the question aims to avoid.