Guest doesn't seem to join

[kumavis]

If you start a game in one window, then open up a 2nd window with the url from the first window, the 2nd window doesn't start/render the game.

[deathcap]

Thought I had this working at one point but I've been making lots of changes, must have broken it somehow, need to investigate..

[deathcap]

Both client and server were instantiated for each window. With deathcap/voxel-fuel@11fea02, the server is only instantiated if window.location.hash is not set (i.e., entered the main page URL directly, instead copying & pasting the baseURL+#roomIDhash it changes to after the page loads), but the game does not fully initialize (even though the client is always instantiated).

[deathcap]

As of the above build, this works:

1. Load http://localhost:8080/
2. Click start
3. Copy the URL (e.g. http://localhost:8080/#3346548901543936) and load it in another tab
4. Click start in the new tab

Able to move around and see the avatars updated in both tabs.

But, this doesn't work:

1. Load http://localhost:8080 and do not click start
2. Copy URL (e.g. http://localhost:8080/#2389504956563456) and load in another tab

The second tab gets stuck (hangs on solid gray) and does not load, unless the first tab's game is started first (but you can start 1st, then reload the 2nd page to join).

[deathcap]

After much more testing (while working on deathcap/voxel-fuel#11), I believe I've begun to see this problem. Sometimes the client doesn't fully load. Chalked it up to rtc.io/switchboard network problems in the past, but now it even sometimes occurs when using rtc-signaller-sw, a completely local messenger. The last message logged is:

data channel opened

Reloading the page often fixes it (maybe a race condition of some sort?)

[deathcap]

Client-only mode

good: https://gist.github.com/deathcap/1c642c49b569682f5937
bad: https://gist.github.com/deathcap/5541cb922e00b255e77c

Interesting difference: after the first 'generators: generated connection constraints', both first report 'rtc-quickconnect: is master, creating data channels: '.. but after the second, the successful case shows:

monitor: signaling state: stable, iceGatheringState: new, iceConnectionState: new bundle.js:110940
couple: setting local description bundle.js:110940
monitor: signaling state: have-local-offer, iceGatheringState: new, iceConnectionState: new bundle.js:110940
monitor: captured state change, new state: have-local-offer, current state: new

and the failure instead shows 'rtc-quickconnect: is master, creating data channels: ["test"] bundle.js:110940'. The third 'generators: generated connection constraints' also shows the failure case selecting itself as the master.

rtc-quickconnect chooses the 'master' based on a numerically-lower randomly-selected UUID, which could very well explain this discrepancy.

[kumavis]

did you file an issue over on rtc-quickconnect?

[kumavis]

@DamonOehlman see above. @deathcap is diagnosing some issues with rtc-quick-connect

[deathcap]

Well I'm not sure its a problem with rtc-quickconnect, more likely a bug in my code :). Will have to investigate further

[DamonOehlman]

I'll definitely take a look and see if I can help with the diagnosis. Might be a couple of days before I get to it though - sorry...

[DamonOehlman]

OK - I've taken a look and yeah I think you are right on the race condition. Rather than implementing your own custom signaller (as per rtc-signaller-sw) I'd probably suggest creating a simple messenger abstraction using postMessage instead (having a look I think this is what you are doing with the alternative signaller).

I've created a simple in memory messenger that is used in tests, here:

https://github.com/messengers/memory

It does start to feel like too many layers of abstraction (you have to pass the messenger to the signaller, which in turn is passed to quickconnect) but it does allow you to switch out components.

I'm going to have a play with the voxpopuli and voxel-fuel module to try and get a better understanding of how the whole thing works as I'm really interested to see this working!

[deathcap]

Yeah rtc-signaller-sw is a custom messenger, using postMessage/onmessage. Spawns a SharedWorker so it can work across multiple browser tabs, while offline. But I also player have the client & server running in the same page (for the single player case), still communicating over WebRTC, looks like I could use the memory messenger there.

(Considering moving towards a more server-centric model, though. Reminiscent of WebSockets, where all the clients talk through a central server – but I like the ability WebRTC gives you of hosting the 'server' in the browser, not to mention SCTP. Since the signaler is for peer discovery if I only have one peer (the server) I'm thinking I might be able to do away with the messenger.. I need to investigate more, but maybe something like https://github.com/cjb/serverless-webrtc)

BTW, I have a live demo up at http://deathcap.github.io/voxpopuli , though I really ought to fix those npm install issues #43 eventually...

[deathcap]

Closing for GH-26