Saturday, August 31, 2013

Peer to Peer MMO

In the last few days, I've built a browser based peer-to-peer message passing system. It was easier than I thought.

I've also been building control panels, now that all the tech is working. I solved the texture curvature problem with a little trig math and storing polar texture coordinates instead of linear spatial. They look nicer.

Incidentally, I tweaked a few things, and the entire interface is now running in-browser (chrome on desktop) at 60fps, which means that technically I am redrawing the consoles (and entire 3D environment) at a faster framerate than ST:TNG was actually broadcast at. Welcome to the future.

Thanks to PeerJS, I now have a functioning peer-to-peer network between the clients using WebRTC. So far it's just carrying 'chat' messages, but it's a very short step to fully encrypted video streams.

Well, I say 'peer-to-peer network', but currently it's the worst kind - a "complete N-way mesh" where every client connects to every other client and sends everything to everyone. To say this is an area of active research is an understatement, but you have to start somewhere.

Given my fairly low needs, that will probably be good for up to a hundred clients, which technically exceeds the number of concurrent PeerJS connections I can have on their free developer account, but the software is open-source, so I can scale up to my own server when needed.

I'm still using Pusher here and there, (just another ODN Conduit type, from inside the code) but it's clear that solution has a different niche. It's more a 'fallback' for highly constrained mobile devices that can't do all the latest WebRTC networking. (Or even WebSockets) Pusher sometimes takes a second or two to get messages across the network, but it's reliable.

When you have two systems with different strengths and weaknesses, the right answer is often to choose both. In fact, if more peer-to-peer style IM services become available, I'll do my best to fold them in too. Heterogeny is good for networks.

Once again, I'm impressed by the quality of work the W3C demonstrated in building the spec, and the talented people at Mozilla and Google who implemented the hard parts while the ink was still barely dry. You might not realize it yet, but your browser has been granted all kinds of new superpowers.

My only gripe is with the quality of the tutorials; too many of the 'official' demos/tutorials are simply incomprehensible. They look more like test cases. Confusing (repetitive and overly long) variable names, poor documentation, no comments, and one-line functions that call other one-line functions instead of inlining for readability.

That's probably why no-one knows about this stuff - the awful tutorials. A similar situation exists for WebGL. I don't blame the W3C or the devs for this: The W3C specs. aren't really meant to be normal-human readable. They have to use a very precise language where terms like "must", "should" and "may" determine what your IF statements need to do. (Although I'd like to find the person who thinks "candidate" is a noun, and give them a piece of my vocabulary.) And the devs are too busy implementing the code and asking for clarifications as needed.

The poor tutorials are really our fault. Mine too, for not writing better expositions of the tech. 'Newcomers' have to document their journey, and discover the common pitfalls and misconceptions that the developers are not longer capable of making, or realizing that we might make. That hasn't happened yet, so being an early adopter means confusion and headaches. WebGL at least has the HeNe tutorials originally written for pure OpenGL and 'ported' across. The best part was their 'lesson structure', not the code. There'a difference between documenting a standard and teaching a class.

While I don't have the time to write a comprehensive tutorial, I can at least say that WebRTC seems to be worth it. Browsers can't go fully peer to peer yet - some 'signalling' by a server is required to set up the connection between consenting browsers, which specifically prevents the general 'try random peers until we get a connection' algorithms - which could potentially turn your computer into a botnet slave if it has a single insecure listener running in a web page. It's a balance, really.

But even this mediated peer-to-peer ability is going to change the web in ways I can't entirely contemplate. The platform is now ready. Let's see what we build upon it.

No comments:

Post a Comment