Server sharing

Introduction

This tutorial demonstrates how you can share the processing power of a single machine between several Rednet-based server applications.

Running that tutorial is a little bit more complicated than with other tutorials as it involves running several applications.

First, you need to run the dispatcher by typing: dispatcher.exe -local (depending on your OS). Then, run as many instances of the tutorial, each with its own network communication port:

serversharing.exe -port 15000
serversharing.exe -port 16000
serversharing.exe -port 17000
...

Finally, open the index.html web page located in [Rednet]/BuildImage/Resources/ServerSharing. You can open up to one page per instance of the running serversharing.exe application.

Each page should display its own version of the rotating torus.

There are almost no difference between the source code of the server sharing tutorial and the one from the HTML 5 client tutorial. It can be seen as a merge between HTML 5 client tutorial and Registering to the dispatcher tutorial. Therefore, it is strongly recommended to have a look at those two tutorials before reading that one.

In fact the sharing of the computer resources is provided by the OS layer itself (whatever your OS is). The OS dynamically adjusts the threads time slices to account for the number of concurrently running instances. If only one client is connected at a time to the machine, the server will use all the machine processing power. If three clients are connected together to the same machine, then each will get 1/3 of the whole processing power, and so on...

Most of the differences come with the HTML page source code. Now, the browser connects first to the dispatcher and then to the rendering server. This is done as follows:

each new client starts by connecting to the dispatcher through a web socket:

// Create a web socket and connect it to our dispatcher.
waiting_for_render_server_url = true;
url_dispatcher = "ws://localhost:18000/stream";
ws = new WebSocket( url_dispatcher );

ws.binaryType = "arraybuffer";

// Web socket callbacks.
ws.onopen = ws_onopen;
ws.onclose = ws_onclose;
ws.onmessage = ws_onmessage;

once connected, the JavaScript callback ws_onopen is automatically called:

function ws_onopen()
{
  // This callback is called first when connecting to the dispatcher.
  if( waiting_for_render_server_url )
  {
      // Ask the dispatcher the URL of the rendering server.
      ws.send( "get_server_url" );
  }
}

It sends the 'get_server_url' string to the dispatcher to request for an url to the next available server. Depending on the current number of running clients, the dispatcher may not satisfy to the user request.

the dispatcher answer is received in the ws_onmessage callback:

function ws_onmessage( msg )
{
  if( ws.url == url_dispatcher )
  {
      // The page is not connected to the rendering server yet. This message
      // comes from the dispatcher and should contain the URL of the rendering
      // server to use to connect to the rendering server.
      if( msg.data == 'none' )
      {
          // No rendering server is available. Display a message.
          alert( "No rendering server available. Please, try again later." );
      }
      else
      {
          // Close the connection to the dispatcher and open the one
          // to the rendering server.
          ws.close();
          
          waiting_for_render_server_url = false;
          
          ws = new WebSocket( msg.data );

          ws.binaryType = "arraybuffer";

          // Websocket callbacks.
          ws.onopen = ws_onopen;
          ws.onclose = ws_onclose;
          ws.onmessage = ws_onmessage;
      }
      return;
  }
  
  // Consider we received a frame.
  img.src = msg.data;
}

The first part of the method is dedicated to handling dispatcher answers (checking the websocket source URL lets us know from who the message is coming). If the message does not come from the dispatcher, we suppose it comes from the rendering server and therefore is necessarily an image in the context of that tutorial (last line of the method).

If all the servers are busy, the page receives 'none'. Otherwise, it receives the URL to connect to. In that case, a new web socket is opened using that URL.

For the remaining part, it looks exactly like the web page of the HTML 5 client web page.

HTML 5 client broadcast

Implementing a rendering server and client next page

Server sharing

Introduction

Description