Transport implementations and roadmap

[JustinDrake]

What implementations of go-libp2p-transport are there? Is there a roadmap for future transports?

Currently

• go-tcp-transport
• ws-transport

In development

• go-utp-transport (needs reviving)
• ipfs-onion-transport (in develpment by OpenBazaar)
• go-udp-transport
• go-libp2p-shs

Wanted

• WebRTC
• QUIC
• I2P

[Kubuxu]

We used to use https://github.com/libp2p/go-utp-transport/ and we would love to see it revived as we think that it took a blame for issues in smux and/or yamux and thus its removal.

[ghost]

There's an onion transport which OpenBazaar are using I think: https://github.com/david415/ipfs-onion-transport

I'm also working on a UDP transport here: libp2p/go-udp-transport#2 -- it can't be used with libp2p yet as we need packet-based interfaces all the way through (working on that too).

[ghost]

Oh and we'd love to have a WebRTC/QUIC transport in go-libp2p, but the respective external go libraries aren't far enough yet.

[whyrusleeping]

I've also talked with @str4d about an I2P transport implementation, which would be pretty cool to have.

[JustinDrake]

I ran ipfs swarm addrs and a couple things surprised me:

• I found a bunch of swarm nodes that advertise /udp and /utp multiaddresses. Is that just for show?
• No node advertise a /ws multiaddress. Is WS actually being used?

[keks]

There also is the relatively fresh protocol Secret Handshake (shs)

[jbenet]

@JustinDrake yes. to talk to js-ipfs in some circumstances. it's not on by default.

The limiting factor in all this is the XTP project: https://github.com/libp2p/xtp. We need XTP to make it easy to use "likely to break" transports. We got bitten hard with go-utp, and we want to use libutp without using cgo for all of go-ipfs. And we want to isolate other possibly faulty transports.

[whyrusleeping]

99% sure it was actually yamux and not go-utp. Ive tried a few times now to break go-utp and can't end up with anything like we were seeing before. Yamux on the other hand gives us wonderful hangs and failures and general terrible memory usage on the regular. On Fri, Dec 2, 2016, 04:12 Juan Benet <notifications@github.com> wrote: @JustinDrake <https://github.com/JustinDrake> yes. to talk to js-ipfs in some circumstances. it's not on by default. The limiting factor in all this is the XTP project: https://github.com/libp2p/xtp. We need XTP to make it easy to use "likely to break" transports. We got bitten hard with go-utp, and we want to use libutp without using cgo for all of go-ipfs. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#157 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABL4HPywWePCuhzACa6pwIOfTe0lP-Avks5rEAsxgaJpZM4K1Heg> .

[avive]

What's the status of this issue? Should utp be working yet for go-libp2p ?

[paralin]

I think I can make a quic transport pretty trivially with quic-go. It might also be interesting to look at making a KCP transport.

[whyrusleeping]

@paralin its worth pointing out that @marten-seemann , one of the main maintainers of quic-go is working on just that. Its turned out to be not that trivial due to different interfaces being needed, and the fact that we don't have client certificate verification implemented into quic-go yet.

However, I agree on KCP. That should be a pretty simple thing to write up, and I would love to see it happen. The utp transport could also likely be fixed up and reintegrated while we're at it, but i'm actually thinking that KCP will outperform it (@xtaci's work is impressive)

[paralin]

So the interesting thing is, the idea behind XTP (External Transport) is very similar to our idea with creating a libp2p daemon. The protocols involved are:

• Between CLI and daemon (grpc at the moment in my impl)
• Between app and daemon (daemon acts as common peer listener for multiple apps)
• Between daemon and external protocols (XTP?)

Can #2 and #3 be the same?

[whyrusleeping]

@paralin we should probably open up a new issue somewhere to discuss XTP

[marten-seemann]

At this moment, quic-go should provide all the features needed for libp2p integration (when we switch the handshake to the TLS-based one, as discussed in libp2p/specs#37).

We had a long discussion in libp2p/go-libp2p-transport#21 about the transport interfaces, and @Stebalien said he wanted to work on implementing this.

[marten-seemann]

Closing this issue. See https://connectivity.libp2p.io/ for current transports offered by libp2p implementations.