Libp2p question: current state of transport protocols and documentation of their integration

Hello everybody,

I recently dived into IPFS and libp2p and really like the ideas of both!
Hope this is the right place to ask these questions regarding libp2p:

  1. Is it currently possible to use udp and/or quic with go-libp2p? If so, is there somewhere a brief explanation on how to do this?

  2. What’s the best place to find detailed information about the design of go-libp2p? Especially to understand the code-relations and the tweaks.

I found similiar (and older) questions that could not give me an answer.

Also from libp2p’s waffle, I couldn’t really figure out the current state of the quic integration.

In I can see that there have been recent changes in order to let transports as quic work. But I can’t really find deeper explanation on how, except the readme of go-libp2p-transport-upgrader. Furthermore, I couldn’t really find a documentation of the go-tcp-transport. This might help to deduce on how to integrate go-libp2p-quic-transport and others.

I went through the examples but still have trouble in putting the network stack together on a lower level.
Unfortunatly, some github readmes don’t provide much information (e.g. the one of go-libp2p-quic-transport)

Any help is appreciated! :slight_smile:

So, the QUIC transport is actually reliable. The primary reasons we want it are:

  1. At most one round-trip handshake.
  2. No head-of-line blocking when multiplexing streams.
  3. Should reduce the amount of “connection tracking” in the kernel/routers so we can keep more connections open without causing problems.
  4. May help with NAT traversal.

State: in progress. It appears to work but we haven’t deployed it on the open net yet as:

  1. The IETF QUIC spec hasn’t been finalized.
  2. We’re still tying up a few loose ends with our implementation.

However, if you want to try it out, you can pass the libp2p.Transport(libp2pquic.NewTransport) option to the libp2p.New constructor. You can listen on QUIC using the libp2p.ListenAddrStrings("/ip4/") option.

Note: this will likely be buggy.

1 Like

Thank you very much!

1. The IETF QUIC spec hasn't been finalized.
2. We're still tying up a few loose ends with our implementation.

Okay I see.

I’ll give the current QUIC implementation a try and see how well it works for me.