3 ms·

i think the point is that the streams themselves require a lot of bandwidth, so you can make the expensive part of the process peer-to-peer instead of having to

i think the point is that the streams themselves require a lot of bandwidth, so you can make the expensive part of the process peer-to-peer instead of having to route the whole thing through a server and pay both inbound and outbound bandwidth costs on the stream. it's not really meant to be a useful tool for making a pure peer-to-peer video service.

viraptor 3y ago
Ok, so it's more of a "direct connection" than "peer to peer" scenario. That makes sense.
- jraph 3y ago
  Doesn't P2P always require some kind of discovery mechanism unless peers know each others? For example for P2P file sharing with Torrent files, a central server (a tracker) that list the current peers? What is different between this and WebRTC? It's only partially decentralized but we still call this P2P, in both cases.
  - Sean-Der 3y ago
    Yes WebRTC does require a discovery mechanism. That is where WHIP/Signaling comes into play. I have a chapter on signaling here https://webrtcforthecurious.com/docs/02-signaling/ https://webrtcforthecurious.com/docs/02-signaling/ I have an example of WebRTC without signaling https://github.com/pion/offline-browser-communication https://github.com/pion/offline-browser-communication. Each side has to agree on things ahead of time. Useful for security cameras/IoT/LAN stuff though!
    - eyegor 3y ago
      Since you seem familiar with it, do you think it's possible to run a webrtc connection over http in a modern browser? I tried for a while to make this work but I gave up because it seemed like in js land it tries to use the getUserMedia apis which aren't allowed in an insecure context. The reason why I was trying was to stream audio + data locally from a device that emits its own wifi network (fully offline due to environment restrictions). It seems dumb to have to serve invalid self signed certs just to set up a webrtc ice handshake.
      - Sean-Der 3y ago
        Unfortunately no. `localhost` is allowed. Could you reverse port forward the service to localhost? That will get around those restrictions.
        eyegor 3y ago
        The service/webserver is running on the device, and clients connect via let's say a cell phone to the devices wifi network. The client talks to the webserver via a wifi network from the device. I don't think there's any way to trick the client into thinking the device is localhost? Maybe some HSTS shenanigans?
        jhugo 3y ago
        Self signed certs would be much easier. Or a CA and certs signed by that; since it’s a controlled environment maybe you can install that CA to the trust store on the viewing devices.
        eyegor 3y ago
        Unfortunately I don't control all of the clients and I'm using self signed certs now. It's just a hassle having to explain to non cs folks how to click past the unsafe prompt which looks to them like an error. Meanwhile I can hack together a poor man's webrtc by sending raw packets over websockets and playback works just fine. I just lose all the real benefits of webrtc (robustness, udp vs tcp, etc.). It feels like it should be possible to work around "secure context" nonsense since I don't access anything on the clients, they just play back a stream from the devices. But chrome/ff tends to block the ice handshake in http mode.
        jhugo 3y ago
        If you’re serving DNS to the clients too, and you’re able to push updates to these devices regularly enough somehow, you can also use real certs with names under some public DNS zone that you control. (Make it resolve to a public IP on the Internet so you can issue/renew the cert, and a private IP on the private network.) But yeah, one way or another, you need a secure context for WebRTC to work. That’s in the spec, and browsers follow it. Perhaps in your context it really is nonsense, but how is the browser to know that your network/physical layer is secure?
  - the8472 3y ago
    > Doesn't P2P always require some kind of discovery mechanism unless peers know each others? That discovery mechanism can be a decentralized network where any contact is an entrypoint. You connect to the network ~once and from that point onward everything is p2p and no fixed servers are involved or in control.
- capableweb 3y ago
  "Peer to peer" is "direct connect". Usually you'd divide what you're talking about into two different steps. Peer discovery, and peer transport. Discovery is how you find other peers, sometimes its via DHT, sometimes it's hard-coded, other times just random walk. But just like in WebRTC, (and in TCP), you need to get the address from somewhere out of band, so you can connect, usually something like a centralized directory. But the transport of data, is P2P, just like TCP. So once you've found the peer and connected to it, all data goes directly between you. Doesn't make it less/more P2P than any other P2P system out there.
  - viraptor 3y ago
    I'm not sure I understand what you mean as p2p transport. What makes HTTP or IMAP not p2p in this description? (You find the peer out of band (DNS) and connect directly to the peer with the data.)
    - notatoad 3y ago
      i'm pretty sure the parent is incorrect in describing TCP as a P2P protocol. TCP (like HTTP or IMAP) has strongly defined client and server roles, the two ends of the connection do not act as peers. P2P should mean that neither end of the connection is taking a specific role, there's no end that could really be classed as server or client.
the8472 3y ago
But OBS is the server serving the stream to everyone. It's using WebRTC in a client-server fashion. There's nothing P2P about it.

viraptor 3y ago

Ok, so it's more of a "direct connection" than "peer to peer" scenario. That makes sense.

jraph 3y ago
Doesn't P2P always require some kind of discovery mechanism unless peers know each others? For example for P2P file sharing with Torrent files, a central server (a tracker) that list the current peers? What is different between this and WebRTC? It's only partially decentralized but we still call this P2P, in both cases.
- Sean-Der 3y ago
  Yes WebRTC does require a discovery mechanism. That is where WHIP/Signaling comes into play. I have a chapter on signaling here https://webrtcforthecurious.com/docs/02-signaling/ https://webrtcforthecurious.com/docs/02-signaling/ I have an example of WebRTC without signaling https://github.com/pion/offline-browser-communication https://github.com/pion/offline-browser-communication. Each side has to agree on things ahead of time. Useful for security cameras/IoT/LAN stuff though!
  - eyegor 3y ago
    Since you seem familiar with it, do you think it's possible to run a webrtc connection over http in a modern browser? I tried for a while to make this work but I gave up because it seemed like in js land it tries to use the getUserMedia apis which aren't allowed in an insecure context. The reason why I was trying was to stream audio + data locally from a device that emits its own wifi network (fully offline due to environment restrictions). It seems dumb to have to serve invalid self signed certs just to set up a webrtc ice handshake.
    - Sean-Der 3y ago
      Unfortunately no. `localhost` is allowed. Could you reverse port forward the service to localhost? That will get around those restrictions.
      - eyegor 3y ago
        The service/webserver is running on the device, and clients connect via let's say a cell phone to the devices wifi network. The client talks to the webserver via a wifi network from the device. I don't think there's any way to trick the client into thinking the device is localhost? Maybe some HSTS shenanigans?
        jhugo 3y ago
        Self signed certs would be much easier. Or a CA and certs signed by that; since it’s a controlled environment maybe you can install that CA to the trust store on the viewing devices.
        eyegor 3y ago
        Unfortunately I don't control all of the clients and I'm using self signed certs now. It's just a hassle having to explain to non cs folks how to click past the unsafe prompt which looks to them like an error. Meanwhile I can hack together a poor man's webrtc by sending raw packets over websockets and playback works just fine. I just lose all the real benefits of webrtc (robustness, udp vs tcp, etc.). It feels like it should be possible to work around "secure context" nonsense since I don't access anything on the clients, they just play back a stream from the devices. But chrome/ff tends to block the ice handshake in http mode.
        jhugo 3y ago
        If you’re serving DNS to the clients too, and you’re able to push updates to these devices regularly enough somehow, you can also use real certs with names under some public DNS zone that you control. (Make it resolve to a public IP on the Internet so you can issue/renew the cert, and a private IP on the private network.) But yeah, one way or another, you need a secure context for WebRTC to work. That’s in the spec, and browsers follow it. Perhaps in your context it really is nonsense, but how is the browser to know that your network/physical layer is secure?
- the8472 3y ago
  > Doesn't P2P always require some kind of discovery mechanism unless peers know each others? That discovery mechanism can be a decentralized network where any contact is an entrypoint. You connect to the network ~once and from that point onward everything is p2p and no fixed servers are involved or in control.
capableweb 3y ago
"Peer to peer" is "direct connect". Usually you'd divide what you're talking about into two different steps. Peer discovery, and peer transport. Discovery is how you find other peers, sometimes its via DHT, sometimes it's hard-coded, other times just random walk. But just like in WebRTC, (and in TCP), you need to get the address from somewhere out of band, so you can connect, usually something like a centralized directory. But the transport of data, is P2P, just like TCP. So once you've found the peer and connected to it, all data goes directly between you. Doesn't make it less/more P2P than any other P2P system out there.
- viraptor 3y ago
  I'm not sure I understand what you mean as p2p transport. What makes HTTP or IMAP not p2p in this description? (You find the peer out of band (DNS) and connect directly to the peer with the data.)
  - notatoad 3y ago
    i'm pretty sure the parent is incorrect in describing TCP as a P2P protocol. TCP (like HTTP or IMAP) has strongly defined client and server roles, the two ends of the connection do not act as peers. P2P should mean that neither end of the connection is taking a specific role, there's no end that could really be classed as server or client.

the8472 3y ago

But OBS is the server serving the stream to everyone. It's using WebRTC in a client-server fashion. There's nothing P2P about it.