Server-Client Connection

The Application Programming Interface (API) of the 3DAVis System

WebSocket Connection

WebSocket is used for connection and communication between the server and the client. WebSocket is a computer communication protocol occurring on a TCP (Transmission Control Protocol) connection over the network layer. uWebSocket is the C++ library used on the server side whereas the WebSocket API JavaScript object is used on the client side.

The uWebSocket C++ library is imported in the main server class to create and listen for a client connection. For development and testing convenience, the server currently calls on communication API (Application Programming Interface) which listens for any connection on port number 9000 on local host. When the connection is set up, the API requires a group of initializing callbacks to be registered in order to have the same pattern as HTTP (HyperText Transfer Protocol). These settings and handlers have to be manipulated according to the context of the project. For instance, settings such as compression and maximum message payload size are set to DEDICATED_COMPRESSOR_256KB and 256*1024*1024 bits respectively. These are the values currently proven to be most efficient for CARTA’s server-client communication and they are also chosen for 3DAVis as the purpose of these settings are similar. On the other hand, handler methods are overridden in the main server class to perform the expected functions of the server.

ZFP Compression

For 3DAVis’ hybrid approach, 3D volume data cubes consisting of float arrays have to be sent to the client for rendering. This data tends to be quite large in size and therefore, needs to be considerably compressed before transfer. ZFP compression library is an open-source software typically used for compressing numerical arrays for high-speed random access. CARTA makes use of ZFP compression on its 2D volume data cubes and was proven to be very efficient in terms of compression size ratio and transfer speedup. 3DAVis incorporates the same library on its 3D data.

In 3DAVis, the implementation of the ZFP library is adapted to deal with 3D volume data. As this project is a proof of concept, the maximum volume data to be compressed per tile is set to be 64*64*64 floats, which is equivalent to 1 Megabyte.

On the client side, ZFP library is imported, and a typical decompression class is constructed using C language. Subsequently, to make the system JavaScript-comprehensible, a pre.ts, post.ts and typyings.d.ts declaration TypeScript files are necessary to build-in the decompression class. These typescripts files along with the ZFP decompression method all compiled into a JavaScript file and a ZFP wrapper WebAsssembly file using Emscripten, a complete compiler toolchain focusing on speed and size using LLVM (Low Level Virtual Machine)

Results

The transfer rate using uncompressed data as compared to compressed data is investigated to show the difference in efficiency and speed of using ZFP compression. On the same note, the factor of compression on several tile sizes is tested and analyzed.

As shown by the blue and gray lines, the average time taken to send through one tile, as small as containing 0.5 MB of floating points data, is at least 200 ms and increases linearly with the tile size. this is because the values of the data cube have to be physically loaded in and stored in a JSON object for transfer. On the contrary, both compressed random data and real data should a considerable speed up in transfer rate. For instance, a tile, as big as 3 MB can be processed under 100 ms. On a performance scale, we are dealing with a system which is 20 times faster when considering 1 MB tiles.

The use of ZFP library on 3D volume data has significantly reduced the size of the data through compression, hence allowing faster transfer. ZPF compression demonstrated over 90% size reduction on random data, and even more effective results on real astronomical data due to grouping of the empty spaces and similar regions in the volume cube.