Peer to Peer Extension to HTTP

[bblfish]

About 5 years ago @Lukasa wrote up an IETF draft named Peer-to-peer Extension to HTTP/2 which allows an HTTP connection to switch between taking on the role of a client and a server.

I found it thinking about a use case of it for Credential Negotiation described HTTP-Signature authentication for Solid.

There may be quite a lot of other use cases for very large deployments of Akka, and for inter Actor communication. I don't know. Perhaps people can use this issue to suggest interesting use cases.

I wonder how difficult something like this would be to implement, assuming that one had concluded that there were really convincing use cases for it. Also it would be interesting to know if that maps nicely to QUIC.

[jrudolph]

Sounds interesting, but as you suggest it should be use-case driven.

[bblfish]

As I understand the Akka gRPC uses HTTP/2 . The designers of that protocol may find P2P HTTP brings some valuable benefits to gRPC. It may be worth asking the right person there? (I don't know that ecosystem, so I would not know who to ask)

[He-Pin]

@bblfish For p2p we may need some distributed adress table。

[bblfish]

@bblfish For p2p we may need some distributed adress table。

Mhh. I am using P2P in the sense of Peer to Peer, that is two way communication on a single connection. For that we don't need distributed address tables. The connection is already open. What is needed is the ability for the contacted server to turn around and become the client. That is what the P2P Extension to HTTP Request For Comments draft proposes.

One use case I am interested in, to answer @jrudolph, is that it makes it possible for the client to pass URLs with relative links that point to the client-qua-server, using a new notation - say >/keys/key#< - to key Identifiers or to Verifiable Credentials that the server can fetch by switching to a client role on the same connection. As a result, the server would not need to open a tcp connection to a resource located on the public web and so won't risk anyone learning from the connection what credentials have been passed. (see my work on httpSig). It would also be more efficient, since the connection is already open, and it would be cacheable, especially if the user uses a did:key:... url because then the resources could be named did:key:.../keys/key# and fetched from the cache the next time the client connects. Also it would remove the need for access control on such material, since the connection is already open.

[jrudolph]

I wonder how difficult something like this would be to implement,

It would probably be possible with the current implementation because client and server already share the core components.

I haven't thought a lot about this feature but it sounds to me like somewhat brittle to use connection-based addressing. To make that work you would have to build customized HTTP clients and server stacks (connection pools, load-balancers, etc), which would add complexity everywhere. Is it really necessary to build that on top of HTTP? If we need to change HTTP to make it work, it should have general applicability which is not clear to me it has.

[bblfish]

I just came across rsocket which also has this peer to peer feature: namely it is a connection oriented protocol where client and server roles can be switched. I am just watching this introductory session RSocket: Solving Real-World Architectural Challenges which gives the quick high level overview of how it works. The following slide addresses the peer aspect 6 min 20 seconds in:

As it is a binary protocol that made me think of Quic (being discussed in issue 3692) and a speedy search found that they have an interesting answer on QUIC and rsockets in their FAQ:

RSocket specifically is intended for layering on top of something like QUIC. QUIC offers reliable transport, congestion control, byte-level flow control, and multiplexed byte streams. RSocket layers on top of those things the binary framing and behavioral semantics of message streams (unidirectional and bidirectional), message-level flow control, resumption, etc.

So I don't yet know enough about rsocket, but it does show that this peer to peer feature is in demand. In any case the question to ask @Lukasa (who wrote the p2p http draft spec) is if the ideas he tried out there would translate well to HTTP/3 (Quic)? Perhaps they are even better there. Also he may have an idea as to how this would relate to rsockets. My guess is that having peer to peer ability to change roles between requestor and the responder would allow RESTful deployments that would otherwise be top heavy if done through rsockets.

[Lukasa]

I don't know RSocket well enough to provide a good answer as to how it relates. As for QUIC, I think it would be substantially easier to define a bidirectional extension to QUIC because it already has the underlying stream representation requirements. Extending HTTP/3 is a little harder but absolutely not a challenge, and indeed a carefully crafted HTTP/3 implementation should be able to run multiple HTTP/3 "connections" within a single QUIC connection.