In a production environment, we have to tell IIS to bind our rhino.compute.exe to a port (in this case port 80). So, any incoming http request (ie. from webcrawlers) was telling IIS to start rhino.compute.exe which in turn would launch compute.geometry.exe. The first thing we need to change was to add a middleware layer which would check for authentication. We were already checking for the API key, but that was happening inside the compute.geometry.exe. If the API keys didn’t match then it wouldn’t process the request. But, we needed that check to happen up one layer in the communication flow (inside the rhino.compute.exe). So, we added some code to make sure that only requests that contain the API get through and start the compute.geometry.exe application.
The next problem we ran into is that the default behavior for rhino.compute.exe was to automatically launch an instance of compute.geometry.exe whenever it started up. For normal local testing and development, this works perfectly since we want both projects up and running whenever we send a request. However, this didn’t work so well inside a production environment. This is because IIS handles the starting and stopping of rhino.compute.exe application based on incoming http traffic. It has a setting called Idle Timeout (we’ll reference this term later) which is set to 20 minutes. If no IIS doesn’t receive any new messages during that time, it shuts the rhino.compute.exe application down. When it receives a new message (again, this can be any random http request from a webcrawler robot), then it will start up rhino.compute.exe. We already modified the code so that those requests were being returned with a 401 status code (not authenticated unless they contained the API key)… but the child compute.geometry.exe was still set to launch whenever rhino.compute.exe was started. So, to fix this we created a new command line argument called --spawn-at-startup whose default value is false (which is what we want in a production environment). If we want compute.geometry.exe to be launched simultaneously to rhino.compute.exe then we simply pass this argument into the command line when the process is started (ie. when rhino.compute.exe is launched whenever Grasshopper starts up). Because of this change, we had to release a small update to Hops (version 0.11.0) .
Remember the Idle Timeout value which I referenced earlier? That’s the IIS setting which tells it when to shutdown rhino.compute.exe. The default is set to 20 minutes. We have a similar setting called idlespan which defaults to 60 minutes and it’s what rhino.compute.exe uses to determine when to shutdown the child processes (ie. compute.geometry.exe). Well, when the 20 minutes had elapsed, IIS was shutting rhino.compute.exe down which in turn would shutdown its children (40 minutes early). So, I modified the bootstrap script so that it now reads the idlespan value from the web.config file and sets the Idle Timeout value for IIS to be slightly longer than that timespan. This way, rhino.compute.exe will always be open a little bit longer than compute.geometry.exe which is what we want.
Lastly, we needed to address the CORS issue you posted about in this thread. We added some code to the rhino.compute.exe server so that the response will return with the proper headers so that web requests shouldn’t fail now.
So, you’re probably asking how you get the latest update code. Well, the simplest answer would be to create a completely new VM image and re-run the bootstrap script. This will pull down all of the latest code and get everything properly setup for you. If you can’t do that, please let me know and I will walk you through the process of manually replacing the rhino.compute files so you can get the latest ones on your VM.