Add a transport that uses UDP or DTLS when multiplexing streams about libchan

[progrium]

Totally agreed somebody should get started on a UDP based transport like QUIC.

[Lennie]

If I'm not mistake, there is only one implementation of QUIC that isn't enabled by default and no specification yet. Or at least no standardization process yet. So probably a bit early for that. :-)

But on the WebRTC datachannel front there are people (developers are CoreOS) that have already started on some code:
https://github.com/coreos/go-webrtc-datachannel
https://github.com/ccding/go-stun

So there was an interrest in doing that, but they stopped.

What is interresting about WebRTC is that is can do NAT traversal.

[progrium]

Yes, super early. Excited about CoreOS's datachannel work. Basically, I'm looking for a mid-level transport layer for Duplex:
https://github.com/progrium/duplex/

I had considered also doing an HTTP2 transport layer for it... but for simplicity, since it needs to be implemented in C very soon, I think we'll just do our simple transport protocol. In the hopes that we can use libchan or something similar when available in C. I would try to help port libchan to C but it's probably too early and there are already many dependencies that would make it difficult.

[progrium]

I'm also happy to contribute my generic net/rpc server reflection code so that libchan can have net/rpc style interface on top of the low level req/rep API. There is a lot of overlap in all our work, so I hope we can figure out a way to collaborate and/or design them to work together. (For example, CoreOS's datachannel could be a libchan transport)

[Lennie]

There are existing SPDY/HTTP2 implementations in C like https://github.com/tatsuhiro-t/nghttp2

[progrium]

Yeah, that's one of the big ones and luckily it's there. Anyway, can't wait for a port to C...

[jbenet]

+1 for QUIC. This would make libchan usable in all high-bandwidth realtime apps, and p2p. (Note that TCP has issues in exposed networks, where anybody can forge RSTs).

[dmcgowan]

If someone wants to participate in building a QUIC golang implementation then I think progress can be made on this issue. Otherwise I will close it for now and we can re-address when there is a finalized QUIC spec or golang implementation.

[sheerun]

What's the status of it?

[dmcgowan]

@sheerun if you know of any Go libraries implementing QUIC I would love to give it a try. Also feel free to advocate for an alternative. As it stands now most this specifications are still fluid and Go implementations are not there.