Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[EPIC] Message orientation design #225

Open
raulk opened this issue Oct 28, 2019 · 0 comments
Open

[EPIC] Message orientation design #225

raulk opened this issue Oct 28, 2019 · 0 comments

Comments

@raulk
Copy link
Member

raulk commented Oct 28, 2019

Introduction

Some of the arguments to introduce message-orientation support in libp2p are well summarised in ipfs/kubo#6481.

The libp2p core team has started conceptualising and building proofs of concept to lay the groundwork for message-orientation. We're doing so addressing the ramifications at different layers of the libp2p model.

We're also keen to explore all the possibilities that open up in terms of transport agility, programmatic transport QoS definition, 0-RTT encrypted request messages, long-lived/virtual sessions, etc.

Design directions

Some of the ideas that are on the table currently:

  • libp2p API for message-orientation, with programmatic QoS definition, such that the transport suite can vary based on the characteristics required by the user, e.g. μTP, Unreliable QUIC.
  • Being sympathetic with the underlying transports. , e.g. leveraging 64k max. datagram size to send speculative initial request messages.
  • Long-lived virtual sessions ("sessions" no longer consume kernel resources, so there's a whole world of possibilities here).
  • Dealing with multiple message oriented transports.
  • Non-interactive protocol agreement, where available. multiselect 2.0 (Draft: multiselect 2.0 design doc #205) as the unified protocol negotiation/selection mechanism for stream-oriented and message-oriented interactions.
  • Security handshake, leveraging 0-RTT data: DTLS, Noise.
  • Multiplexing / Multipacket protocol.
  • Dealing with message fragmentation, when payloads are above max. PDU size.
  • Shimming reliability, ordering and congestion control on user-land (or relying on transports like uTP).

Team

The team working actively so far on this epic comprises @bigs (leading it), @yusefnapora (main author of the libp2p Noise spec), and @marten-seemann (drafting multiselect 2.0).

👉 If you'd like to help shape things and hack on the proof of concept, please comment on this issue! 🙌

Design documents

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Triage
Development

No branches or pull requests

1 participant