haulage is currently in charge of sensing user input (i.e. monitoring network usage) as well as actuating on this input (i.e. issuing iptables commands). This is a problematic architecture for us as we add more billing features, including but not limited to:
- subscription model
- ability to "cut off" a user via the admin portal, or otherwise override haulage's rules
- ability for admin portal to see exactly what is going on (right now it just queries database)
I believe the right approach is to split haulage into (1) the monitoring software that writes updates to the database and (2) an actuator that takes all sorts of input (from haulage as well as the database rules, etc.) and is in charge of enacting all changes into the system. This gives us all sorts of tools/solutions for network management. We could grow/fold this into a PCRF or not, depends on what else we want to do with it.
haulage is currently in charge of sensing user input (i.e. monitoring network usage) as well as actuating on this input (i.e. issuing iptables commands). This is a problematic architecture for us as we add more billing features, including but not limited to:
I believe the right approach is to split haulage into (1) the monitoring software that writes updates to the database and (2) an actuator that takes all sorts of input (from haulage as well as the database rules, etc.) and is in charge of enacting all changes into the system. This gives us all sorts of tools/solutions for network management. We could grow/fold this into a PCRF or not, depends on what else we want to do with it.