search

postech-dao / simperby

The ultimate BFT blockchain engine for decentralized organizations with powerful trustless interoperability.
MIT License
70 stars 38 forks source link

Tracking issue for WebRTC + NAT Traversal #499

Closed junha1 closed 11 months ago

sejongk commented 1 year ago

A SDP message used in webrtc-rs (https://github.com/webrtc-rs/webrtc) includes media settings and ICE candidates. We won't use this for media communication, so we may use hard-coded media settings. However, ICE candidates are dynamic, because it depends on network situation. Therefore, I guess we have to figure out how to keep this valid for a long time using keepalives and coordinating timeouts in ICE. If it's not possible, we may have to introduce a signalling server for the exchange of the latest SDPs.

ref. https://datatracker.ietf.org/doc/html/rfc8445#page-54 https://github.com/webrtc-rs/webrtc/blob/3f1c67e1fc0004415897635ee47bec0b7962563f/webrtc/src/api/setting_engine/mod.rs#L107

junha1 commented 1 year ago

I have two important question

  1. NAT traversal is only about the server right? Then is WebRTC asymmetric? In other words, It is something that the server node takes care?
  2. If then, what should a client node do to connect the server opened by a public STUN server? Is it possible even if the client node can't perform NAT traversal as a server?
  3. What's the final interface of Rust WebRTC? Is it a raw TCP socket?
sejongk commented 1 year ago

@junha1

  1. NAT traversal makes a peer behind NAT accessible by other peers. It can be said that NAT traversal makes it act as a server in some sense.
  2. WebRTC provides a RTCDataChannel instance that represents a network channel which can be used for bidirectional peer-to-peer transfers after the ICE procedure. Therefore, it requires both peers to be able to finish NAT Traversal. If a peer isn't able to connect with other through a STUN server, I guess it's impossible to connect them using WebRTC. For this case, they can communicate through a common server-client model used in Simperby now after detecting a failure of using WebRTC.
  3. As mentioned above, it provides a RTCDataChannel instance. I'm not sure we can extract a raw socket from this and extracting it is a right way. This is a quite high-level instance as it deals with data communication over layered protocols (ref. https://hpbn.co/assets/diagrams/f91164cbbb944d8986c90a1e93afcd82.svg). I think it's better to keep the current communication way and provide a new WebRTC option. Because I'm not sure the WebRTC can be completely compatible with and perfectly replace the current interface of Simperby.