4 ms·

I also decided to learn WebRTC and built a video chat app project: https://zonko.chat https://zonko.chat The last time I did any p2p networking was back in 200

I also decided to learn WebRTC and built a video chat app project: https://zonko.chat https://zonko.chat The last time I did any p2p networking was back in 2002 or something when you still had to do it all manually. We used all sorts of fun tricks like NAT hole punching, and using little script endpoints to capture and forward along port and public IP address information. It was fun to see that all of this has since been formalized under the "ICE framework". I was surprised to see that the STUN spec is only 12 years old now, despite the techniques involved being used for at least 20 years, probably more like 30+. So if anyone who's new to this whole p2p world feels that WebRTC and the ICE framework is confusing or onerous, I would point out that just a short while ago these were basically just a handful of heuristic techniques developed through trial and error over the years. It's really much easier nowadays! zonko.chat only took me 12 or so hours to build (and seems to be well-supported by chrome and ff, even mobile). Edit: Upon reflection, I don't even remember how I learned about some of them. The concept of TURN was probably one that I, and many thousands of others, invented from scratch due to necessity (failed to punch the hole? fall back to this custom relay I wrote in perl). STUN was an easy one to figure out yourself, too. I don't remember how I learned about hole punching though. Probably a forum or a book. Or possibly just an experiment ("what if the two connections touch somewhere in the internet at the same time... hey wait, it worked?") What's interesting to me is that the core "ICE" concepts (hole punching, STUN, TURN) are still pretty simple even in their mature, formalized, scientific form. But the concept of "SIP" is much more sophisticated today than it was back then.

dvirsky 6y ago
I worked for a company developing a custom P2P video streaming protocol. It was amazingly hard to get working properly and testing all the quirks in different routers from different manufacturers. The combination of all the NAT strategies (I think there were 5 main ones) created quite a matrix of possible ways that things can work, and you had to implement and test them all before there was any kind of standard way to do it. We built a mock internet with dozens of consumer routers, as many as we could get our hands on. We eventually got it to work and that company exists to this day, but I think they switched to WebRTC long ago.
vxNsr 6y ago
> The last time I did any p2p networking was back in 2002 or something when you still had to do it all manually. > It's really much easier nowadays! zonko.chat only took me 12 or so hours to build While it may have only taken you 12 hours to build in "real time" I'd say you've been "building" it for the last 20 years. If a newbie tried to do this they could expect to spend a few weeks or more on the project would be my guess.
- bkanber 6y ago
  That's a good point! I did not need to relearn core concepts. The bulk of that 12 hours was actually spent debugging negotiation and timing/race issues in the signaling/SIP layer. Even for me, figuring out how the WebRTC API is supposed to work was a little difficult.
  - vxNsr 6y ago
    I hope I didn't come off as overly aggressive, the comment was mostly for myself, I was feeling badly that there was no way I would be able to do implement something like this in 12 hours. Often veterans here will talk about projects they trivially did. but unless you dig into their profile and find out who they are it feels like every joe-shmo on hn is a 1/2mil+ SWE at google.
    - bkanber 6y ago
      No no, that didn't sound aggressive at all! Though I still wouldn't say the project was trivial, just very limited in scope. And had I done everything perfectly -- meaning, being able to stream code from my head with no errors -- the project may only have taken 3 hours. That's how small it is. I think the finished product is 800 lines of code, server and client together. It's conceptually very small too. (Maybe this is a 'veteran' skill as well, being able to keep things small.) My point is that a whole 75% of the time I spent on this project was just me flailing around with stuff that wasn't working as I expected (that's relatable at all experience levels!). Perhaps it's true that veterans can get through certain things more quickly than novices can, but we're not immune to the 80/20 rule either! We just get stuck on different types of problems.

dvirsky 6y ago

I worked for a company developing a custom P2P video streaming protocol. It was amazingly hard to get working properly and testing all the quirks in different routers from different manufacturers. The combination of all the NAT strategies (I think there were 5 main ones) created quite a matrix of possible ways that things can work, and you had to implement and test them all before there was any kind of standard way to do it. We built a mock internet with dozens of consumer routers, as many as we could get our hands on. We eventually got it to work and that company exists to this day, but I think they switched to WebRTC long ago.

vxNsr 6y ago

> The last time I did any p2p networking was back in 2002 or something when you still had to do it all manually. > It's really much easier nowadays! zonko.chat only took me 12 or so hours to build While it may have only taken you 12 hours to build in "real time" I'd say you've been "building" it for the last 20 years. If a newbie tried to do this they could expect to spend a few weeks or more on the project would be my guess.

bkanber 6y ago
That's a good point! I did not need to relearn core concepts. The bulk of that 12 hours was actually spent debugging negotiation and timing/race issues in the signaling/SIP layer. Even for me, figuring out how the WebRTC API is supposed to work was a little difficult.
- vxNsr 6y ago
  I hope I didn't come off as overly aggressive, the comment was mostly for myself, I was feeling badly that there was no way I would be able to do implement something like this in 12 hours. Often veterans here will talk about projects they trivially did. but unless you dig into their profile and find out who they are it feels like every joe-shmo on hn is a 1/2mil+ SWE at google.
  - bkanber 6y ago
    No no, that didn't sound aggressive at all! Though I still wouldn't say the project was trivial, just very limited in scope. And had I done everything perfectly -- meaning, being able to stream code from my head with no errors -- the project may only have taken 3 hours. That's how small it is. I think the finished product is 800 lines of code, server and client together. It's conceptually very small too. (Maybe this is a 'veteran' skill as well, being able to keep things small.) My point is that a whole 75% of the time I spent on this project was just me flailing around with stuff that wasn't working as I expected (that's relatable at all experience levels!). Perhaps it's true that veterans can get through certain things more quickly than novices can, but we're not immune to the 80/20 rule either! We just get stuck on different types of problems.