There are many factors to consider when it comes time to deploy HOOPS Communicator as part of your web application. This section focuses on different components that you need to consider in order to create a working production deployment for model viewing utilizing HOOPS Server. This section is presented in an environment agnostic way. The exact implementation details will vary depending on which technologies and platforms you are utilizing in your application stack.
There are common components that all deployments need to utilize to create a working deployment capable of streaming data to clients.
Whether you are creating a single or multi server setup, you will need to decide how your Stream Cache models will be stored and later accessed for viewing. HOOPS Server has two specific requirements relating to Stream Cache models that should be kept in mind when choosing a storage solution:
Random access is required for WebSocket streaming support.
Models consisting of multiple files should have all dependencies present in the model directory before the session begins.
Satisfying these requirements can differ based on the type of storage solution that you are employing.
Network file storage
Network file storage is convenient for use with HOOPS Communicator since it provides both random access and can be mounted to multiple machines. This allows you to conveniently store your models in one location and have them easily accessible to your viewing and conversion storage.
In cloud hosted environments, network storage tends to be more expensive and incurs a monthly cost over time. Solutions like Google Cloud Platform’s Filestore and Amazon Web Services EFS provide extremely fast performance which can make loading very large assemblies quicker but incur a monthly cost per GB of data stored.
Object storage such as Amazon’s S3 or Googles Cloud Storage offer a lower cost way to store files. The disadvantage is that the files need to be completely pulled out of storage before streaming can begin as they do not offer random access. For smaller files, the time to transfer from object storage to a viewing service is usually negligible.
It is recommended to establish your WebSocket connections over standard ports. This means 80 for ws and 443 for wss. Often, configurations for corporate, or public settings networks will block traffic over nonstandard ports due to security concerns. Failure to use standard, trusted ports can result in your users not being able to access your services. Additionally, you are limiting the amount of ports that need to be open on your host machine, which increases the overall security of your application.
In a multi-machine setup, load balancers allow you to distribute load among multiple machines and scale your application as demand increases. Often, your application will make use of a third-party load balancer, such as an Amazon Elastic Load Balancer or a Google Cloud Load Balancer. Both options support the WebSocket protocol and are suitable for use with HOOPS Communicator.
In a production environment, traffic should be encrypted using SSL. In a multiple machine setup, SSL can be terminated at the load balancer. In a single machine setup, it can be terminated at the proxy level. If you are using HOOPS Server as your proxy with wss, it will terminate the SSL connection. It is important to ensure that DNS is configured correctly to be compatible with your SSL certificates. For example, if you have a SSL certificate for .mydomain.com, then you will need to ensure that websocket connections are opened with a uri along the lines of wss://communicator.mydomain.com.
A single machine setup is a straightforward way to deploy the HOOPS Server in proof-of-concept environments, or for use in situations where the traffic volume will be low enough to be handled by a single machine. A typical single machine deployment typically looks like this:
Things to note about this deployment include:
Models are converted using HOOPS Converter on another server and placed on a network file store that is mounted to both the conversion server and the viewing server.
DNS has been configured for viewers.example.com to point to this viewing server. The Communicator server has been configured with SSL certificates that are valid with the DNS entry.
Communicator Server is configured to act as a websocket proxy
Presumably, the files are being placed on the network share as they are converted using HOOPS Converter. If both HOOPS Converter and HOOPS Server were on the same server, then network storage could be replaced with local file storage. In production environments, it is not recommended to run both HOOPS Converter and HOOPS Server on the same machine for performance reasons.
A multi-server setup allows your application to more easily scale in response to demand. In addition to HOOPS Server, this configuration makes use of a load balancer to distribute the load across multiple viewing servers. This load balancer is most often a third-party component such as AWS Elastic Load Balancer or Google Cloud Load Balancer.
Things to note about this deployment include:
Models are converted using HOOPS Converter by another service and placed on a network file store that is mounted to the servers for both the conversion service and the viewing service.
DNS has been configured for viewers.example.com to point to the load balancer. The load balancer has been configured with SSL certificates that are valid with the DNS entry.
Each viewing server is registered with the load balancer, and it is assigning sessions to the servers using a round robin strategy.