Category Archives: JanusVR

Janus Presence Server Part 3

 

6 x JanusVR clients and the Janus Presence Server running on my PC

6 x JanusVR clients and the Janus Presence Server running on my PC

So, it’s up and running 🙂  Kinda.

The 6 x JanusVR clients above are connected to the Janus Presence Server running within a CentOS 7 instance (Vagrant and Virtualbox).  All on my PC!

I added a bit of console logging to the server to make it easier to know what it was up to.

Progress check:

A. Develop JMeter Scripts
A1. Install Eclipse XX DONE
A2. Compile JMeter DONE
A3. Run JMeter DONE
A4. Create simple test set to call against Janus Presence Server API – share on GitHub – FAILING
A5. Maybe see if the Janus Presence Server scales…

B. Build Janus Presence Server Box
B1. Create CentOS 7.0 Vagrant box DONE.
B2. Upload Vagrant base box to Atlas DONE
B3. Configure new CentOS 7.0 box with Node – upload to Atlas  DONE (Download here!)
B4. Configure new CentOS 7.0 box with Janus Presence Server preinstalled – upload to Atlas – IN PROGRESS

C. JMeter Test Client Box
C1. Build JMeter Base Test Client Box
C2. Build janus presence test client box – upload to Atlas

So after quite a lot of messing around I have a CentOS 7.0 box which I can kinda mess around with 🙂  I’ve installed Janus Presence Server on it and it works – but will probably rebuild to a cleaner version before I upload a copy onto Atlas.

Some notes:

  • Default requiretty from has been commented out of **/etc/sudoers** file
/etc/sudoers
#
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear.
# You have to run "ssh -t hostname sudo <cmd>".
#
#Defaults requiretty

  • The latest feature on vagrant which will replace the default vagrant key with a new one was a bit of a pain in the butt… during packaging it would replace the default key with a safer random one.  This meant that if you downloaded the version that I uploaded to Atlas earlier on then you would be prompted for a login details before being to SSH in… however, there was a workaround – simply switch off the box that you want to package before kicking off the vagrant packaging process.
  • Need to sort out the firewall rules.  At the moment I just switch off the firewall to make things work.
systemctl stop firewalld

Once the Janus Presence Server was up and running  I could mess around with it.  It was particularly interesting to see the interactions between each of the JanusVR client.  Head spinning amount of potential here.  Fascinating stuff! – especially the way that users can move shared objects around… wooo magic!  Wondering how the various Janus Presence Server’s may share information one day.  It was also interesting to see the connections and disconnections with the various servers when I walked around the vr space.  I’ll post up a video to show this later on.

Janus Presence Server Part 2

So I created a “jmx” project. JMeter allows me to create a pretend user who will have their own session. This user can connect using a TCP socket.

I have not created my own server yet so I thought I would try connecting up to the VRSites defalt one just to see if things would work.

Only a single cheeky connection – don’t want to start a Denial Of Service attack by accident!

So I sent this:

{"method":"logon","data":{"userId":"oculushut", "version":"23.4","roomId":"345678354764987457"}}

But nothing was sent back….

2015/03/22 00:41:58 INFO - jmeter.engine.StandardJMeterEngine: Running the test! 
2015/03/22 00:41:58 INFO - jmeter.samplers.SampleEvent: List of sample_variables: [] 
2015/03/22 00:41:58 INFO - jmeter.gui.util.JMeterMenuBar: setRunning(true,*local*) 
2015/03/22 00:41:59 INFO - jmeter.engine.StandardJMeterEngine: Starting ThreadGroup: 1 : JanusVR Clients 
2015/03/22 00:41:59 INFO - jmeter.engine.StandardJMeterEngine: Starting 1 threads for group JanusVR Clients. 
2015/03/22 00:41:59 INFO - jmeter.engine.StandardJMeterEngine: Thread will continue on error 
2015/03/22 00:41:59 INFO - jmeter.threads.ThreadGroup: Starting thread group number 1 threads 1 ramp-up 1 perThread 1000.0 delayedStart=false 
2015/03/22 00:41:59 INFO - jmeter.threads.ThreadGroup: Started thread group number 1 
2015/03/22 00:41:59 INFO - jmeter.engine.StandardJMeterEngine: All thread groups have been started 
2015/03/22 00:41:59 INFO - jmeter.threads.JMeterThread: Thread started: JanusVR Clients 1-1 
*********2015/03/22 00:41:59 INFO - jmeter.protocol.tcp.sampler.TCPClientImpl: Using platform default charset:windows-1252 *********????
2015/03/22 00:42:10 INFO - jmeter.gui.action.Start: Stopping test 
2015/03/22 00:42:10 INFO - jmeter.threads.JMeterThread: Stopping: JanusVR Clients 1-1 
2015/03/22 00:42:10 WARN - jmeter.threads.JMeterThread: Interrupting: JanusVR Clients 1-1 sampler: Connect 
2015/03/22 00:42:10 ERROR - jmeter.protocol.tcp.sampler.TCPSampler: org.apache.jmeter.protocol.tcp.sampler.ReadException: Error reading from server, bytes read: 0

[PAUSED UNTIL I KILLED IT]

at org.apache.jmeter.protocol.tcp.sampler.TCPClientImpl.read(TCPClientImpl.java:120)
 at org.apache.jmeter.protocol.tcp.sampler.TCPSampler.sample(TCPSampler.java:414)
 at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:434)
 at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:261)
 at java.lang.Thread.run(Unknown Source)
Caused by: java.net.SocketException: Socket closed
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(Unknown Source)
 at java.net.SocketInputStream.read(Unknown Source)
 at java.net.SocketInputStream.read(Unknown Source)
 at org.apache.jmeter.protocol.tcp.sampler.TCPClientImpl.read(TCPClientImpl.java:107)
 ... 4 more
2015/03/22 00:42:10 INFO - jmeter.threads.JMeterThread: Thread is done: JanusVR Clients 1-1 
2015/03/22 00:42:10 INFO - jmeter.threads.JMeterThread: Thread finished: JanusVR Clients 1-1 
2015/03/22 00:42:10 INFO - jmeter.engine.StandardJMeterEngine: Notifying test listeners of end of test 
2015/03/22 00:42:10 INFO - jmeter.gui.util.JMeterMenuBar: setRunning(false,*local*)
Looks like the system is talking with the wrong encoding...perhaps need to set UTF8 explicityl somewhere.

I go to the following file:

F:\dev\eclipse_workspace\jmeter-trunk\bin\jmeter.properties

And add the following (the skeleton for this is just commeted out):

tcp.charset=UTF-8

However, this does not work…

FAIL… powershell connects up to Babylon URL a couple times, but does not appear to work consistently. Kind of difficult working blind (I cannot see what is happening on the server side).  Here’s the gist for that.

Time to make some progress on the back end.  Progress check…

A. Develop JMeter Scripts
A1. Install Eclipse XX DONE
A2. Compile JMeter DONE
A3. Run JMeter DONE
A4. Create simple test set to call against Janus Presence Server API – share on GitHub – FAILING
A5. Maybe see if the Janus Presence Server scales…

B. Build Janus Presence Server Box
B1. Create CentOS 7.0 Vagrant box <<—- Try and complete this to help with A4…
B2. Upload Vagrant base box to Atlas
B3. Configure new CentOS 7.0 box with Node – upload to Atlas
B4. Configure new CentOS 7.0 box with Janus Presence Server preinstalled – upload to Atlas

C. JMeter Test Client Box
C1. Build JMeter Base Test Client Box
C2. Build janus presence test client box – upload to Atlas

I’ve used Vagrant boxes before, but wanted to try and build a base image that I knew all about.

Downloaded the CentOS 7.0 “Everything”.  Get it here.  About 7GB in size! 😛

This blog entry was for Ubuntu rather than CentOS, but I found it useful.

I made sure “vagrant” user was an administrator in my box. And, this box has UK keyboard by default 😀

I also setup a bridged network to the internet to allow me to carry out updates. The NAT’d adapter mentioned in the article was not enough – Mental note: I changed this back to NAT only later.

Things I did:
updated packages
wget installed
bridged network
 bzip2

It’s not locked down so for testing/experimenting only!

It’s using the default Vagrant key for SSH access!

Found that my version of Vagrant did not allow me to package… bug… sucky:

F:\dev\vagrant_base_boxes\vagrant-centOS64-oculushut>vagrant package --base vagrant-centOS64-oculushut
F:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/machine.rb:153:in `action': wrong number of arguments (2 for 1) (ArgumentError)
from F:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.7.1/plugins/commands/package/command.rb:83:in `package_vm'
from F:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.7.1/plugins/commands/package/command.rb:66:in `package_base'
from F:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.7.1/plugins/commands/package/command.rb:42:in `execute'
from F:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/cli.rb:42:in `execute'
from F:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/environment.rb:301:in `cli'
from F:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.7.1/bin/vagrant:174:in `<main>'

I am using 1.7.1 and apparently that had a bug which meant that you could not package…
Apparently this was fixed in 1.7.2 of Vagrant so I downloaded the very latest version of Vagrant (1.7.2) and upgraded to this on my Windows 7 box.

I’ve been playing around with a mix of Vagrant, Docker, VMWare, Virtualbox for a little while now and found that these version compatibility issues crop up fairly regularly…

At this point I kept on getting this error, but just worked around it by switching off the box before trying to package it:

F:\dev\vagrant_base_boxes\vagrant-centOS64-oculushut>vagrant package –base vagr
ant-centOS64-oculushut

==> vagrant-centOS64-oculushut: Clearing any previously set forwarded ports...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.
Command: ["modifyvm", "vagrant-centOS64-oculushut", "--natpf1", "delete", "SSH"]
Stderr: VBoxManage.exe: error: Failed to assign the machine to the session (E_FAIL)
VBoxManage.exe: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component Machine, interface IMachine, callee IUnknown
VBoxManage.exe: error: Context: "LockMachine(a->session, LockType_Write)" at line 471 of file VBoxManageModifyVM.cpp

Turns out that this was symptomatic off vagrant having issues because my ssh using the default vagrant account was working properly – I believe vagrant will try to ssh into the server to shut it down or “take over” when packaging.  When there was success I received the following message:

F:\dev\vagrant_base_boxes\vagrant-centOS64-oculushut>vagrant package --base vagrant-centOS64-oculushut
==> vagrant-centOS64-oculushut: Clearing any previously set forwarded ports...
==> vagrant-centOS64-oculushut: Exporting VM...
==> vagrant-centOS64-oculushut: Compressing package to: F:/dev/vagrant_base_boxes/vagrant-centOS64-oculushut/package.box

So I test the new box locally…

F:\dev\vagrant_base_boxes\vagrant-centOS64-oculushut>vagrant box add vagrant-centOS64-oculushut package.box
==> box: Adding box 'vagrant-centOS64-oculushut' (v0) for provider:
 box: Downloading: file://F:/dev/vagrant_base_boxes/vagrant-centOS64-oculushut/package.box
 box: Progress: 100% (Rate: 968M/s, Estimated time remaining: --:--:--)
==> box: Successfully added box 'vagrant-centOS64-oculushut' (v0) for 'virtualbox'!

Init?

F:\dev\vagrant_base_boxes\vagrant-centOS64-oculushut>vagrant init vagrant-centOS64-oculushut
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

vagrant up?

FAIL

F:\dev\vagrant_base_boxes\vagrant-centOS64-oculushut>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'vagrant-centOS64-oculushut'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: vagrant-centOS64-oculushut_default_1427 052246917_94908
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
 default: Adapter 1: nat
==> default: Forwarding ports...
 default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
 default: SSH address: 127.0.0.1:2222
 default: SSH username: vagrant
 default: SSH auth method: private key
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
 default: Warning: Connection timeout. Retrying...
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.
If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.
If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.
If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

Turns out that there was a problem with the SSH all along….

I needed to go back in and edit the network ONBOOT setting mentioned here.

/etc/sysconfig/network-scripts/ifcfg-enp0s3
ONBOOT=yes and reboot

And then I find out I hadn’t setup the permissions properly either.

Needed to enter this:

Defaults:vagrant !requiretty

Into here:

/etc/sudoers.d/vagrant

Also, I found that the packaging process got rid of the ONBOOT=true setting I made and it meant that I had to to switch on the GUI in the Vagrantfile, reboot and then set this manually… I’ve reported this on vagrant’s GitHub repo here to see if there is something which I am missing.

So:

A few known issues with this release which need to be fixed later:

1. ONBOOT needs to stay as yes
2. requiretty needs to stay as not needed
3. need to work out why the session cannot start straight after vagrant up
4. Looks like guest additions does not start

Workaround:

Workaround:

A. Go to folder you want vagrant box to be deployed to and “vagrant init”
B. Change “base” to “oculushut/vagrant-centOS64-oculushut” in file
C. Uncomment this in the generated Vagrantfile:

config.vm.provider "virtualbox" do |vb|
 # # Display the VirtualBox GUI when booting the machine
 vb.gui = true
 #
 # # Customize the amount of memory on the VM:
 # vb.memory = "1024"
end

D. Add this line (a hotly debated recent change which will get rid of a new piece of functionality which would mean that the generic keys would be replaced (meaning that you would not be able to share this so easily… would need to share keys too etc – thought it would be easier just to remove since this is not a production box should not be used to store anything sensitive anyway… this automation stuff is a bit of a pain eh? https://github.com/mitchellh/vagrant/pull/4707):

config.ssh.insert_key = false

(Just “vagrant destroy” if you tried to “vagrant up” before making the change and start again)

E. vagrant up
F. login via the GUI that pops up vagrant/vagrant
G. go to /etc/sysconfig/network-scripts
H. sudo vi ifcfg-enp0s3
I. Change ONBOOT=no to yes
J. Save (:wq!)
K. Reboot: sudo shutdown -r now
L. If you did this quick enough then you’ll find that the initial “vagrant up” session is still trying to connect and it will eventually connect. However, at this point I get a message saying that GuesAdditions is not running for some reason and the system tries to run:

/etc/init.d/vboxadd setup

And then fails because it needs tty. And then I notice that /etc/sudoers.d/vagrant has had the following treatment:

The Defaults:vagrant !requiretty was removed
It’s now readonly 🙁
So, change permissions, add the line back in and reboot…

chmod 777 vagrant
 vi vagrant
 Add this: Defaults:vagrant !requiretty
 wq!
 chmod 440 vagrant
 shutdown -r now

M. vagrant up still fails, but vagrant ssh will work and puTTy on 127.0.0.1:2222 works

And, the box has been uploaded here…. hope it saves somebody some time!  Pretty generic CentOS 7 box!

Progress check:

A. Develop JMeter Scripts
A1. Install Eclipse XX DONE
A2. Compile JMeter DONE
A3. Run JMeter DONE
A4. Create simple test set to call against Janus Presence Server API – share on GitHub – FAILING
A5. Maybe see if the Janus Presence Server scales…

B. Build Janus Presence Server Box
B1. Create CentOS 7.0 Vagrant box DONE.
B2. Upload Vagrant base box to Atlas DONE
B3. Configure new CentOS 7.0 box with Node – upload to Atlas <–Time to hit B3!
B4. Configure new CentOS 7.0 box with Janus Presence Server preinstalled – upload to Atlas

C. JMeter Test Client Box
C1. Build JMeter Base Test Client Box
C2. Build janus presence test client box – upload to Atlas

Janus Presence Server Part 1

Janus VR is something like a VR web browser. If you run it then you can browse VR content that is being served up by web servers. I’ve written a bunch of stuff on this in the past and James McCrae’s website has loads of info. Plus there are all my Janus VR videos and you can check out the conversation on Reddit as well as Oculus dev forums.

However, did you know that it is the Janus Presence Server open source project started by LisaLionheart which allows each Janus VR client to share information with others?  This is what allows each of the Janus VR clients know where other avatars are geographically, who else is in the same virtual space and things like chat.  When you startup JanusVR the default installation connects up to “babylon.vrsites.com” and default port is “5566”.  This is where an instance of the Janus Presence Server runs.   Since release 38.0 of JanusVR, users room owners can also add a special tag so that anybody who enters that room goes to a specific Janus Presence Server – thus allowing the system to scale.

Anyhow, I thought I would just spend a bit of time poking around the Janus Presence Server to see how it worked – it’s open sourced afterall!

I doubt I will get to the end, but thought the following could be fun:

A. Develop JMeter Scripts
A1. Install Eclipse XX
A2. Compile JMeter
A3. Run JMeter
A4. Create simple test set to call against Janus Presence Server API – share on GitHub
A5. Maybe see if the Janus Presence Server scales…

B. Build Janus Presence Server Box
B1. Create CentOS 7.0 Vagrant box
B2. Upload Vagrant base box to Atlas
B3. Configure new CentOS 7.0 box with Node – upload to Atlas
B4. Configure new CentOS 7.0 box with Janus Presence Server preinstalled – upload to Atlas

C. JMeter Test Client Box
C1. Build JMeter Base Test Client Box
C2. Build janus presence test client box – upload to Atlas

Here’s what I have done so far (A1, A2 and A3):

  • Cloned jmeter from github: https://github.com/apache/jmeter
  • I decided I would just try and startup jmeter. I didn’t really expect it to work, but there was a jmeter.bat file in the /bin folder…
F:\dev\eclipse_workspace\jmeter-trunk\bin>jmeter.bat
 Error: Unable to access jarfile ApacheJMeter.jar
 errorlevel=1
 Press any key to continue . . .
  • eclipse.readme file said the following about the eclipse.classpath file that comes with the source:
Eclipse.classpath
 -----------------
 [This has been tested with Eclipse 3.2 up to 4.3.2. It may not work with other versions.]
  • Thought I would try and keep things as simple as possible on this first try. Downloaded older version of Eclipse (Kepler 4.3.2) here:

http://www.eclipse.org/downloads/packages/eclipse-standard-432/keplersr2

  • Used ant that came with eclipse to download a bunch of libraries which worked fine.
[eclipse directory]\plugins\org.apache.ant_1.8.4.v201303080030\bin\ant.bat
  • However, error occurred when I then tried to build.
BUILD FAILED
 F:\dev\eclipse_workspace\jmeter-trunk\build.xml:792: Class not found: javac1.8
  •  Turns out that there was a bug in Ant versions older than 1.9  🙁

http://stackoverflow.com/questions/20702626/javac1-8-class-not-found

  • And the version of ant with eclipse Kepler is really old… so I tried the suggested workaround:
[eclipse directory]\plugins\org.apache.ant_1.8.4.v201303080030\bin\ant.bat -Dbuild.compiler=javac1.7
  • This failed with the following error:
BUILD FAILED
 F:\dev\eclipse_workspace\jmeter-trunk\build.xml:792: Unable to find a javac compiler;
 com.sun.tools.javac.Main is not on the classpath.
 Perhaps JAVA_HOME does not point to the JDK.
 It is currently set to "F:\Program Files\Java\jre1.8.0_20"
  • So I setup my environmental variable to point to my copy of JDK: F:\Program Files\Java\jdk1.8.0_20
  • Tried again, and…
BUILD SUCCESSFUL
 Total time: 12 seconds
  • Yay! File pops out here:
[eclipse_workspace]\jmeter-trunk\bin\ApacheJMeter.jar

And now I try [eclipse_workspace]\jmeter-trunk\bin\jmeter.bat again and the GUI starts up. I read through the API documentation for Janus Presence Server and it looks pretty comprehensive.  I forked the repository and updated the API doc too.  Sent a pull request over to LisaLionheart to see if she takes to update (bit more verbose, but I preferred it).  Anyway….Apache JMeter… new toy… now to try A4… ke ke ke ke

JMeter