From the documentation at http://peerjs.com/dash

Using PeerServer Cloud

PeerServer Cloud is a cloud host for the server portion of PeerJS. You can begin using your keys in PeerJS immediately. Simply pass in the key in the options to the Peer constructor

var peer = new Peer({key: 'pkh3oln5gwpfd2t9'});

I think it may be that there is not a field entry for the use of the cloud server from peerjs. I generated a key there to just test the module without the complication of setting up a peerjs server. I would guess by altering the code temporarily I could add our key to the system for this test. Would you suggest the file and a line number where I might be able to do this?

Comments

Chris Pergantis created an issue. See original summary.

kenianbei’s picture

kenianbei CreditAttribution: kenianbei commented

Yep, it's in js/app/PeerService.js, line 45.

I think you'd want to change

        service.Peer = new Peer(null, Settings.options);

to

        service.Peer = new Peer(null, {key: 'pkh3oln5gwpfd2t9'});

Did you still plan on submitting a patch for this if the peerjs server is working?

Also, if I were you, I'd contact the peerjs team to see if they are still planning on pushing this out as a supported service. AFAIK they are no longer working on the github code. However there is another company in Japan that has continued working on the code from their own fork, and seem to be providing a more robust service: https://github.com/nttcom/peerjs

Chris Pergantis’s picture

Chris Pergantis CreditAttribution: Chris Pergantis as a volunteer commented

Kenianbei, Thanks for the info. We are not planning to utilize their server in the long run. We have had some difficulty in getting the peerjs module / Drupal site to connect properly to the server we have installed. This will be a test to see if we swap out servers if it will work. If all goes well we can then return to our server and complete the installation. Just plain ole swap troubleshooting.

Chris Pergantis’s picture

Chris Pergantis CreditAttribution: Chris Pergantis as a volunteer commented

I am not wanting to appear presumptuous, however I would like to let you know of our findings. Looking into the javascript console we found attempts by the site to connect to "skyway.io". None of the settings of 0.peerjs.com:9000 are being used. If they were we would expect at least one connection attempt to show up in the java script console. I would think that the "skyway.io" was your test server while you developed the system. Is it possible that within the code being used that a propensity remains to connect to "skyway.io"?

Please let me know if there is some other reason as to why the only attempted server connection is to "skyway.io"; I could be way off base with the preceding assumption.

To test this idea I have established an account at "skyway.io" and have obtained an API key. Could you let me know how I might implement this connection within your code?

kenianbei’s picture

kenianbei CreditAttribution: kenianbei commented

Ahh... that's because by default, if you are using drush prdl to download the library, the library being downloaded is the skyway branch. I didn't think about that... to connect to the peerjs.com server with an api key you'll need to manually download and replace the peer.min.js file from https://github.com/peers/peerjs.

Not sure what their implementation is for connecting, but most likely its the exact same, as I outlined before.

Chris Pergantis’s picture

Chris Pergantis CreditAttribution: Chris Pergantis as a volunteer commented

Just a quick notice the lines 84 and 90 of peers.admin.inc are both referencing the port of the server. We are still having trouble getting the module to send any requests to an outside server now that we have changed the library over to the git version at https://github.com/peers/peerjs. Our team will be doing a detailed code review today and most likely will have a patch in a week or so. What is the wording you would like to have on line 94 of peers.admin.inc?

Chris Pergantis’s picture

Chris Pergantis CreditAttribution: Chris Pergantis as a volunteer commented

Here is our recent finding about making a connection to 0.peerjs.com - At least we are getting it to recognize our settings.

Mixed Content: The page at 'https://accelerateddesign.com/peerjs_chat/3#' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://0.peerjs.com:9000/{our key}/id?ts={generated id}'. This request has been blocked; the content must be served over HTTPS.

We have tried changing the settings from 0.peerjs.com to https://0.peerjs.com with no improvement. We also changed the port 9000 to cleared but this was the most curious part - the port remained as 9000 in the above error message. We have flushed Drupal cache and placed a new port number to see if that error might change. It did not.

Is there a cache we need to flush for the port change to be used?

Where do we make the connection SSL?

kenianbei’s picture

kenianbei CreditAttribution: kenianbei commented

I'm pretty sure if you use an API key the port is hard coded as 9000. This is because their node server runs on 9000.

Mixed content will not work: https://github.com/peers/peerjs/issues/320

I'd try over http for testing. I'm pretty sure https should work though.

I'm still recommending to just run your own on heroku though, as per there directions.

P.S. I'm at DrupalCon Asia, and on vacation for a month, so I may not respond more to these issues.

Chris Pergantis’s picture

Chris Pergantis CreditAttribution: Chris Pergantis as a volunteer commented

Kenianbei,

Great! have fun with the Drupal camp. We have been to two recently in our area (we pay for and take the employees and interns to regional camps every year). Perhaps we will meet at one in the future. I am not expecting you to answer for the next few weeks. Your attention to the camp and your travels is completely understandable.

I want to thank you for the work you have provided on this contributed module. Without it I would have no idea of where to start. Your informative replies and encouraging remarks have also been helpful. From our on-going discussion I am believing most of the "fallbacks" that we keep seeing have nothing to do with your module but more they exist within the peerjs libraries either from skyway or peerjs. It seems in order to have a library that does not impose settings out of the control of the Drupal module we might need to alter the library to depend on those module settings. This would require a Git branch or a different repository. Do you have an opinion on this?

We will next do a diff on the two libraries to see how they differ. From there we can assess what might need to be corrected.

-Chris

kenianbei’s picture

kenianbei CreditAttribution: kenianbei commented
Status: Active » Closed (won't fix)

Hi Chris,

I had some time today (vacation starts tomorrow XD) to look into peerjs.com. I was able to get http working no problem with minor changes to the module (as outlined above in the 1 line change). However HTTPS will not work without changes to the peerjs.com library. I see no reason to try to get it working with their service since it seems abandoned.

I highly recommend doing your testing on heroku using the automated install button located at https://github.com/peers/peerjs-server

I'm closing this issue as won't fix, with the caveat that if they start supporting their service again we can reopen.

Ultimately, we may need to reevaluate the wisdom of using peer-server and peer.js at all as a webRTC wrapper. There are other more mature libraries now such as https://simplewebrtc.com/

Chris Pergantis’s picture

Chris Pergantis CreditAttribution: Chris Pergantis as a volunteer commented

Thanks