js-libp2p icon indicating copy to clipboard operation
js-libp2p copied to clipboard
verified publisher icon libp2p

feat: WebRTC-Direct support for Node.js

Open achingbrain opened this issue 1 year ago • 3 comments

Supports listening and dialing WebRTC Direct multiaddrs in Node.js.

Depends on:

  • [x] https://github.com/libp2p/go-libp2p/issues/2827
  • [ ] https://github.com/paullouisageneau/libjuice/pull/248
  • [x] https://github.com/paullouisageneau/libdatachannel/pull/1206
  • [x] https://github.com/paullouisageneau/libdatachannel/pull/1207
  • [x] https://github.com/murat-dogan/node-datachannel/pull/258
  • [x] https://github.com/murat-dogan/node-datachannel/pull/259
  • [ ] https://github.com/murat-dogan/node-datachannel/pull/260
  • [ ] https://github.com/murat-dogan/node-datachannel/pull/256
  • [ ] https://github.com/paullouisageneau/libdatachannel/pull/1211

Closes:

  • https://github.com/libp2p/js-libp2p/issues/2581

Change checklist

  • [x] I have performed a self-review of my own code
  • [ ] I have made corresponding changes to the documentation if necessary (this includes comments as well)
  • [x] I have added tests that prove my fix is effective or that my feature works

achingbrain avatar Jun 07 '24 16:06 achingbrain

I read the code a bit, in this implementation when Peer B listens, it first listens for incoming stun packets using dgram, extracts the ufrag, and then establishes a connection with Peer A from another port. This works fine in a direct network connection. But if Peer A is behind NAT, this type of connection will fail because the NAT detects incoming packets from another port, which was not accessed from inside before.

xicilion avatar Jun 12 '24 03:06 xicilion

I haven't got to the point of testing NAT traversal yet, still a lot of PRs to land in the deps.

I was wondering if each RTCPeerConnection could negotiate it's own NAT traversal via STUN/TURN but it would probably be less resource intensive to have UDPMUX on a single port, I agree.

achingbrain avatar Jun 12 '24 08:06 achingbrain

I was wondering if each RTCPeerConnection could negotiate it's own NAT traversal via STUN/TURN.

From the logic of the code, even though multiple RTCPeerConnections share a single UDP socket in UDPMUX mode, each of them manages their own status separately and there is no difference compared to regular RTCPeerConnections. This means that the negotiation process for them is also no different from regular RTCPeerConnections.

xicilion avatar Jun 12 '24 13:06 xicilion

I have forked node-datachannel as @ipshipyard/node-datachannel with all of the above patches applied.

Now CI is passing I'm going to merge this to allow further experimentation.

achingbrain avatar Feb 12 '25 14:02 achingbrain