Over the past few years, while developing applications to run alongside GenieACS, I’ve encountered several problems with the current GenieACS scripting solution.
Firstly, performance issues: The current provisioning scripting method necessitates that the script run multiple times during each inform. This puts excessive pressure on the hosting computer, often requiring an increase in the inform time for devices in some ISPs to prevent the CPU from running out of resources when processing heavily loaded scripts.
Secondly, race conditions frequently occur, particularly when dealing with a variety of vendors each having different ACS implementations. Scripts running concurrently and entering preset loops are a common problem.
Thirdly, the current scripting solution lacks an effective error-handling approach. When a script encounters an error, it simply fails, and there’s no fallback mechanism in place to handle the error. This proves especially challenging when dealing with various vendors, each with their own bugs.
Finally, handling long-running and complex scripts is problematic. The existing system terminates scripts when an inform stops, creating difficulties when attempting to run a command that affects the current connection, sometimes even triggering a fault. The ability for a script to resume from its last point at the next inform would be highly beneficial.
Given these issues, I’ve been considering some solutions, with the primary idea being an alternative scripting system that operates on a separate server.
Design Principles:
- Separate Server: The system should have the ability to run on an independent server or even a virtual machine (VM). This will allow the CWMP server to solely focus on managing the CWMP requests. Separating the scripting server would permit script processing in the cloud, where more CPU and memory resources are available.
- Multi-server Capability: The system should handle multiple CWMP servers, useful in operations where multiple GenieACS VMs are running.
- Linear Scripting: Each line of the script should run once.
- Error Handling: The system should include a mechanism for identifying and addressing errors within the script.
- No Parallel Script Execution: For each device, only one script should run at a given time, simplifying debug, fault tracking and preventing preset loops.
- Separate Database: The system should have an independent database, giving programmers access to a collection for writing as needed.
- Flexible Data Control: Script-managed requests won’t necessarily trigger an update in the devices collection. It will be up to the programmer’s discretion to decide how to store date and when to save the collected data in the database.
- Variable Access: All variables (such as Events, cpeRequestId, etc.) should be accessible to the programmer at all times.
- Compatibility: While the goal is to use only this new solution, I understand that it might not be feasible. Therefore, the new scripting server should execute after all current provisioning scripts have exhausted their commands and the ACS server is preparing to stop the inform.
- TypeScript Option: Users should have the option to write their scripts in TypeScript to prevent type, typo, and null-pointer-related errors.
Proposed Solution:
- The CWMP server should have the option to connect to an RPC server. Once configured, GenieACS will start requesting instructions from the server.
- When the first request begins, the RPC server will decide whether to start a new script or if the current message should go to an existing script.
- When running, the script will give a promise-like command such as “await getParameterValues()”. At this point, the RPC server script will send the commands provided by the script to GenieACS, and the promise will hang until the server responds.
Rough Architecture:
Script sample:
