5 ms·

I tried PeerJS in a pet project a few months ago. The one thing that became immediate is peer to peer over browsers isn't great. You can basically throw testing

I tried PeerJS in a pet project a few months ago. The one thing that became immediate is peer to peer over browsers isn't great. You can basically throw testing out the window, there is no good way to emulate p2p locally. Trying to test my PeerJS project involved having two computers, and occasionally required one to be connected through a VPN. Problems I found was connecting over LAN was really flaky. Most times, Chrome to Chrome was fine. Chrome to firefox was also mostly fine. Firefox to Firefox had a pile of quirks - connections only worked if I completely quit firefox, and started it again with just my two windows, and even then, sometimes that connection failed. The ICE/Turn server stuff is also a mess. I ended up installing and hosting a coturn server on digital ocean, and it was a pain. Documentation wasn't great, stackoverflow/forum questions were typically old, and there didn't appear to be any obvious alternatives. I also tried simple-peer by feross, which seemed to be fine, and most quirks remained as browser issues. I ended up ditching webrtc and went with a server with websockets. With peer to peer, I'm stuck using a server somewhere, so I'd rather use a websocket server. Webrtc just introduced too many unknown variables. Is there a problem with an ICE/Turn server? Is there a LAN issue? Can browsers vendors properly do p2p to each other without a bunch of "if firefox, do this, if chrome, do this, if something else, panic"? The websocket server took 100% of these concerns out of the equation. I'd love to be able to use webrtc confidently, but with the current tools for implementing and testing, I don't think I can say it is for myself. So I think the TLDR is that webrtc peer to peer isn't really consumer-ready. The browser support seems a little hit and miss, testing through a LAN appears to be very flaky, and testing via node/some other framework is spotty at best.

corytheboyd 6y ago
I’m curious, does your solution not need audio and/or video? I could agree that WebRTC is overkill if only data channels are used, but AV blows complexity up massively doesn’t it?
- mrozbarry 6y ago
  Audio and video would have been a nice to have, which is why I was going this route. I also wanted the data to never touch an external server so users could know their data is as safe as the people they share it with. The data for this app, by nature, isn't important to have a history, so just being able to share data immediately was all I needed, and p2p seemed like the optimal first step. I cut out audio and video from my features, and for the most part, things are working just fine.
  - corytheboyd 6y ago
    I’m a bit confused, are you using WebRTC for the peer to peer connection or not? If you’re not, doesn’t that imply a server in the middle that all data is sent through? Sorry don’t mean to be challenging, just want to understand how people work in this space!
    - mrozbarry 6y ago
      I'm not anymore, because it was incredibly frustrating to test locally. My original goal was p2p, for two reasons. I didn't want a backend if I didn't need one, and I wanted to maintain a lot of privacy features for users. So now I just have a websocket relay server instead, which isn't my favorite, but it does the job.
dboreham 6y ago
> there is no good way to emulate p2p locally Disagree. You can implement functional tests with a loopback signal server. You can implement e2e tests with network emulation (e.g. using iptables/iptraf). Automated testing using the browser WebRTC stack (obviously run basic tests in Node.JS for convenience) is annoying but doable with puppeteer or the like. Just takes time and effort. The point of WebRTC vs hairpin'ed websocket streams is that the bulk data doesn't pass through intermediate hosts, making the system less costly to run and more privacy preserving. Note that any TURN service required can always be provided or controlled by one of the parties -- it doesn't have to be a centralized service.
- mrozbarry 6y ago
  Sure, you can do all that, but then I think you're in docker-land or something similar, and you are essentially building a system that works the way you think it does, and it may not reflect reality (arguably that is most testing). And I think if someone is to build this containerized system for testing, it shouldn't necessarily be some app developer like me, it should be someone like the chromium or firefox team that know exactly how the browsers expect to communicate
- erickj 6y ago
  "You can implement e2e tests with network emulation (e.g. using iptables/iptraf)" or via network isolation through networking namespaces (e.g. with podman and lxc)
- f430 6y ago
  what you just described is over my head and I found parent's experience to be a genuine frustration with inconsistent production/development.
eeZah7Ux 6y ago
Not to mention the huge security risk.

corytheboyd 6y ago

I’m curious, does your solution not need audio and/or video? I could agree that WebRTC is overkill if only data channels are used, but AV blows complexity up massively doesn’t it?

mrozbarry 6y ago
Audio and video would have been a nice to have, which is why I was going this route. I also wanted the data to never touch an external server so users could know their data is as safe as the people they share it with. The data for this app, by nature, isn't important to have a history, so just being able to share data immediately was all I needed, and p2p seemed like the optimal first step. I cut out audio and video from my features, and for the most part, things are working just fine.
- corytheboyd 6y ago
  I’m a bit confused, are you using WebRTC for the peer to peer connection or not? If you’re not, doesn’t that imply a server in the middle that all data is sent through? Sorry don’t mean to be challenging, just want to understand how people work in this space!
  - mrozbarry 6y ago
    I'm not anymore, because it was incredibly frustrating to test locally. My original goal was p2p, for two reasons. I didn't want a backend if I didn't need one, and I wanted to maintain a lot of privacy features for users. So now I just have a websocket relay server instead, which isn't my favorite, but it does the job.

dboreham 6y ago

> there is no good way to emulate p2p locally Disagree. You can implement functional tests with a loopback signal server. You can implement e2e tests with network emulation (e.g. using iptables/iptraf). Automated testing using the browser WebRTC stack (obviously run basic tests in Node.JS for convenience) is annoying but doable with puppeteer or the like. Just takes time and effort. The point of WebRTC vs hairpin'ed websocket streams is that the bulk data doesn't pass through intermediate hosts, making the system less costly to run and more privacy preserving. Note that any TURN service required can always be provided or controlled by one of the parties -- it doesn't have to be a centralized service.

mrozbarry 6y ago
Sure, you can do all that, but then I think you're in docker-land or something similar, and you are essentially building a system that works the way you think it does, and it may not reflect reality (arguably that is most testing). And I think if someone is to build this containerized system for testing, it shouldn't necessarily be some app developer like me, it should be someone like the chromium or firefox team that know exactly how the browsers expect to communicate
erickj 6y ago
"You can implement e2e tests with network emulation (e.g. using iptables/iptraf)" or via network isolation through networking namespaces (e.g. with podman and lxc)
f430 6y ago
what you just described is over my head and I found parent's experience to be a genuine frustration with inconsistent production/development.

eeZah7Ux 6y ago

Not to mention the huge security risk.