W3bworld: in-browser 3D visualisation of network state
Introduction
W3bworld evolved from the ideas that drove L3DGEWorld - provide an interactive 3D interface with which to monitor and interact with the state of a network. The key difference between the two projects is that W3bworld runs inside of a web browser, utilising new features of HTML5 websockets and WebGL 3D rendering.
The structure of W3bworld follows that of L3DGEWorld, including the usage of the l3dgecomm protocol to communicate between input/output daemons and the W3bworld environment.
Technologies
The current implementation of W3bworld utilises the following technologies: Socket.IO for HTML5 websockets, Processing.js for HTML5 3D rendering and NodeJS for the application server.
Structure
The client is a webpage which contains a HTML5 canvas. The main functions of the client are rendering, camera control and keeping a cache of information it has received from the server. If the client loses connection with the server (eg, a loss of network connection or the server crashes), the client can continue operating with stale data.
The client and the application server communicate using Socket.IO. All communication is event-based. That is, one side will emit an event and associated data, which will trigger a function call inside the receiver program. Typically, the communication will be via HTML5's websockets. If websocket negotiation fails - for example, a proxy that does not support websockets - Socket.IO provides a framework that allows it to fall back to a number of other technologies, including AJAX and Flash sockets.
The server mediates between l3dgecomm input/output daemons and all connected w3bworld clients. The server stores information regarding the state of all entities in the environment.
Input and output daemons provide and receive state information to and from the W3bworld environment and communicate with the W3bworld environment using l3dgecomm protocol. Input daemons send information about specific entities to the W3bworld server, such as spin and bounce rate and names of the metrics. Output daemons receive events that W3bworld clients have triggered.
The Client
The client is separated out in to a number of modules, each contained within a separate file:
- w3b-core.js: contains functions mostly dealing with user input
- w3b-entity.js: contains functions and classes for storing and using state information about each entity
- w3b-hit.js: contains hit-detection for triggering actions on an entity
- w3b-camera.js: contains camera manipulation functions
- w3b-socketio.js: contains network communication functionality
- gfx.pde: contains the processing.js scripts for rendering the world
In addition to these, there are a number of third party libraries in use:
- jquery-1.7.2.min.js: jQuery, used for simpler DOM manipulation and JS shorthand
- processing.bug608.js: a modified version of Processing.js that allows for .obj file loading
- fullscreenapi.js: a short script to enable the fullscreen API in web browsers that support it. In the near future, fullscreen support will become standardised and this script will not be needed
- socket.io.min.js: the client-side Socket.IO implementation.
The Server
The server is separated out in to two modules:
- w3bworld.js: contains entity management and client communication code
- l3dgecomm-server.js: contains a Node.js l3dgecomm module
The interface between w3bworld.js and l3dgecomm-server.js has one event in each direction, making it simple to modify. Installation & Configuration describes how to implement a new module to put in place of l3dgecomm-server.js. Likewise, the l3dgecomm-server.js module can be used in other projects with similar ease.
