System and Network Configuration

System Configuration

The F.A.S.T. Cloud SDK runs with default system configuration using standard non-SSL through port 8088 with the most common quality and performance settings.  Default behavior is described below and is changed by modifying the ./foviaserver/config/configuration.xml.    The server must be restarted for any changes to take affect.  The following system configuration and their default settings are described below:

<nodePort>8088</nodePort>
<useSSL>0</useSSL>
<sessionTimeout>0</sessionTimeout>
<quality>3</quality>
<fps>8</fps>
<jpegInteractive>50</jpegInteractive>
<jpegFinal>95</jpegFinal>
<usePNG>0</usePNG>
<octreeSmoothing>0</octreeSmoothing>

The server version and configuration settings are displayed in http://localhost:8088/version

Network Settings (Ports and SSL)

nodePort, and useSSL specify the network protocol and port to be used.  Separate port configuration settings are used for SSL and non-SSL, although only one can be used at one time.  

The port can be changed to any valid unused port, such as 9123, after restarting your server, validate that the test helloFovia app adjusted accordingly  (<FoviaServerIPaddress>:9123/apps/hellofovia/) still works correctly.

 To enable SSL, set useSSL to 1 and restart your server.  You can test this by using https protcol with example app https://localhost:8088/apps/hellofovia, which uses the supplied test certificate.  Notice the use of https and the port change on the URL.  Documented source code is found inside ./foviaserver/public/apps/hellofovia/hellofovia.js.  In a production environment, replace the demo server.crt and server.keys that are provided in the ./foviaserver/ssl directory with your company's official certificate.

Session Timeout

The default client sessionTimeout is set to 0 seconds of inactivity.  Modify this to the desired value if you want the server to force a disconnection after a certain amount of inactivity.

Quality  / Performance

Default values for quality and performance are explained below.  Care must be taken when changing these settings since they affect all users on the system. There are two types of quality / performance metrics in the system, those that relate to network, and those that relate to the actual rendering (and ray casting). 

The network quality and performance trade off affect how much bandwidth is required for transferring images over the network, and specifically the amount of JPEG compression for interactive and final quality images.  This is largely independent of rendering quality that is described below.
 
There are two levels of JPEG compression:  jpegInteractive is set to 50/100 and jpegFinal is set to 95/100.  Typically during mouse interactions, many interactive jpegInteractive frame are generated (such as during the render() call during a mouseMove operation).  These are quick rendering operations with more aggressively compressed JPEG image.  On mouseUp, a renderFinal() operation is triggered and results in a jpegFinal frame.  The rendering engine will take longer to generate higher quality images, and JPEG with less aggressive compression will be used for these.  Setting jpegInteractive to any higher value will yield almost no noticeable visual difference, but will strain low-bandwidth network connections.  Setting with jpegInteractive or jpegFinal to lower values will only yield lower quality images, but will typically not improve network bandwidth utilization except in the most constrained network environments (such as those will less than a 4Mbps connection).

By default, render() and renderFinal() will generate JPEG images using the compression setting as defined by jpegInteractive or jpegFinal.  If usePNG flag is set to 1, the RenderEngineContext2D will use lossless PNG compression for renderFinal for all 2D rendered images, which may be useful for diagnostic viewing of 2D DICOM images.  Intermediate images created using the render() call, such as those generated during a mouseDrag operation will still use JPEG.  If it is desired to only generate lossless PNG, simply never invoke renderFinal() on a RenderEngine2DContext (this is NOT advised as this could dramatically affect interactive network performance).

The rendering quality and performance trade off affects how much time the rendering engine spend on ray casting during the actual render operation.  Internally, the quality tells the engine how much time (or effort) should be spent for each frame.  Valid numbers are 0 (raw), 1(draft), 2 (better), 3 (best), and 4 (print).  In general 3 (best) is a reasonable number for most system.  The 4 (print) setting is only used when rendering to a high projection matrix for rendering of professional printed publications.  Numbers less than 3 may yield slightly better interactive performance on lower-end CPU. 

The fps setting is the more interesting one in that it allows you to specify a target frame rate in the range of 1 to 60, and the engine will attempt to match this frame rate, reducing overall interactive rendering quality when necessary.  The final quality image will always look great.  The value 0 is sometime used during testing to determine the absolutely maximum frame rate for a given scenario.

octreeSmoothing is the final setting that is used to determine the type of resampling should be performance when building the internal octree.  The default value of 0 is no resampling.  Many times the input data is already smoothed, so additional smoothing should not be performance.  The value of 1 allows for tri-linear resampling.  The value of 2 allows for tri-cubic resampling.  Values of 1 or 2 are useful when the dataset is particularly noisy.

It is advised that you work closely with your Fovia engineering and support team to adjust the values based on your hardware requirements, system load (both dataset size and number of concurrent users) as well as customer expectation.

The above system configurations are global for all clients. Fovia.ServerContext.setRenderQuality()Fovia.ServerContext.setJPEGQuality(), Fovia.ServerContext.setSessionTimeout() and  Fovia.ServerContext.createOctree() allow each of these values to be changed globally from within your application.

Please see the ClientConfig example app as an example.  Documented source code is found inside ./foviaserver/public/apps/hellofovia/config.js

Web Server App Configuration and Deployment

Cloud SDK provides default web application configuration settings defined by the <url> in ./foviaserver/config/configuration.xml.  The "urls" tag contain strings (relative file paths) that are appended to ./foviaserver/public directory and Cloud SDK binds the URL to the specified directory.   For production environments, only public visible directories and any subdirectories should be listed that are required by your application.   As an example for how this is used, refer to the following lines:

        <url>/apps/hellofovia/:id</url>
        <url>/apps/hellofovia/</url>


This provides the mapping from the URL <FoviaServerIPaddress>:8088/apps/hellofovia/* to the physical directory ./foviaserver/public/apps/hellofovia.  From a server perspective, all files inside the hellofovia directory to be exposed through the web server.  It also provides the default mapping when the specific file is omitted, and allow localhost:8088/apps/hellofovia to map to hellofovia/hellofovia.html.  This does not expose subdirectories, those must also be exposed explicitly.  Be sure to restart the Fovia web server after adding new entries for your web applications.

A test URL entry has been added that you may create and start creating your first application:

        <url>/apps/test/:id</url>
        <url>/apps/test/</url>

Simply create the directory test ./foviaserver/public/apps, add an HTML and JavaScript file, and it can be accessed from your browser.