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

Samsung Gear VR Headset: Virtual Reality Made Real

Tablets, as we know them, are devices merely used for checking e-mail, social networking and playing apps. However, further developments are being made where mobile virtual reality is now turning into an actual reality. While most tech companies are active in enhancing their line of smartwatches, Samsung, one of the largest electronics company in the world, has ventured into another major new category: virtual reality headsets. 

Announced last September, the popular tech company recently released their first ‘’next generation’’ wearable named Gear Virtual Reality headset, or Gear VR. It was a collaborative project between Samsung and Facebook’s Oculus VR specialists. The aforementioned Gear VR has an array of games and is mounted with VR movie viewing software. 

Moreover, the VR headset doesn’t depend on computers or a gaming console to function. Instead, users slip a Galaxy Note 4 tablet into the $200 headset. According to Samsung, “Powered by Oculus technology, the Samsung Gear VR delivers a completely new way to experience and consume mobile content.”

Certainly, they are believed to be more concerned with building awareness in virtual-reality technology, and hope that early adopters will follow along. 

What to Expect from Gear VR

The virtual reality headset’s hardware is said to be provided by Samsung, while its software is made by Oculus. It basically is designed with an optical lens with a 96-degree field of view. Having said that, wearing the device also offers a complete 360-degree generated three-dimensional image.

Furthermore, the headset is designed with multiple sensors including accelerator, geomagnetic and gyrometer. It even has adjustable features that can be manipulated by users who are either nearsighted or farsighted. This “Innovator Edition” is built with movie viewing software wherein watching a film using the Gear VR makes users feel like they’re at an actual cinema.

As aforementioned, the Gear VR exclusively relies on Galaxy Note 4 as it represents the baseline equipment required for the virtual reality to work.  What works best with the VR headset are such tablets with superior specifications specifically its screen density and processing power. But for now, it only activates with the Galaxy Note 4.

The Korean consumer electronics giant has also partnered with a number of game developers to build up content for the gadget. Having said so, Gear VR users may enjoy some games for the system which includes the much anticipated Marvel’s Avengers: Age of Ultron. Aside from that, users may also experience iMAX, Cirque du Solei and enjoy DreamWorks VR.

Further enhancements are also expected including its implementation of a service called Milk VR that is intended for apps and offers various channels for music, sports, and action. Until then, Gear VR users may download several apps via the Oculus store. 

The Battle for Virtual Reality is on

Virtual reality is an area that has garnered excitement all throughout the world in the past few decades. Even though mainstream consumers don’t show enough indication of interest, several tech companies embarked on this particular project. In July, Facebook acquired Oculus for $2 billion while Sony is constantly pushing into VR with its Project Morpheus headset that is designed to be an extension to its PlayStation 4 video game console.

Given this yet another milestone for the tech industry, some developers believe that virtual reality is the next big thing in gaming after mobile. In fact, there are already mobile companies working on Android devices for virtual reality. Furthermore, game developers actually are already targeting wearables as an appealing platform for games.

The Gear VR headset is currently out for sale in the US market and will be sold to other countries early next year.

Guest Writer:
KyleAlbert2
Kyle Albert
@KyleAlbert9
Wise Tomorrow Blog

Photo: Maurizio Pesce
Flickr