Hi!
Looking at Websockets from a SNMP perspective, I would like to thank you for implementing counters - I just added them to SNMPstats.
In addition, I would like to be able to discover sub-protocols used (msrp, sip). I fail to see how I can do that now. Do we have a Core API for publishing read-only data from modules? I guess we maybe could use PVs or XAVPs for that. An ugly way would be to implement RPC in SNMPstats and issue RPC commands internally to fetch data, but that means a lot of serializing that really is not needed as SNMPstats generally fetches one parameter (OID) at a time, not complete sets.
Also, some of the modparam parameters could be exposed as cfg params - which would make it easier to change them at runtime with sercmd, but also expose them in SNMPstats. I think keepalive_interval and keepalive_timeout are candidates for this.
Cheers!
/O
----------------------------- Copy of my commit message, just to repeat myself:
Hint to developers: If you add statistics and selects in your module, you make it very easy to add SNMP support for your module. Then SNMPstats can just use generic APIs to find your data. Please also add a generic way of finding out if a module is configured and used too, if possible. Sometimes modules are just loaded, but not used anywhere. Better to reflect real data in SNMP if possible.
Using the old "SER" way of using selects for config data that is allowed to change at runtime opens up for SNMP writes to manage your module as well.
And of course, using selects and counters/statistics variables also helps the RPC interface, so it's both cool and the Right Thing To Do (TM).
Yes, commit messages can be informative as well. :-)
Hello Olle,
In addition, I would like to be able to discover sub-protocols used (msrp, sip). I fail to see how I can do that now. Do we have a Core API for publishing read-only data from modules? I guess we maybe could use PVs or XAVPs for that. An ugly way would be to implement RPC in SNMPstats and issue RPC commands internally to fetch data, but that means a lot of serializing that really is not needed as SNMPstats generally fetches one parameter (OID) at a time, not complete sets.
I've added a whole slew of new counters so you can see what is going on at the sub-protocol level. Feel free to add them to SNMP if they will help.
Note that the frames received and transmitted counters for SIP and MSRP only count frames containing SIP and MSRP messages. So the existing total frames received and transmitted counters will contain larger numbers as they include control frames too.
I have also added the sub-protocol used to the dump MI command, but not sure that is really useful. The WebSocket MI commands were only really added to help with testing. For example, the dump command won't help much on a system with thousands of active connections - simply too much data.
The WebSocket module doesn't actually contain any RPC commands at all. Not sure what use they would be for this module anyway.
Also, some of the modparam parameters could be exposed as cfg params - which would make it easier to change them at runtime with sercmd, but also expose them in SNMPstats. I think keepalive_interval and keepalive_timeout are candidates for this.
If you can point me at a clear example of where this done elsewhere I'll be happy to add it.
Regards,
Peter
30 mar 2013 kl. 13:29 skrev "Peter Dunkley" peter.dunkley@crocodile-rcs.com:
Hello Olle,
In addition, I would like to be able to discover sub-protocols used (msrp, sip). I fail to see how I can do that now. Do we have a Core API for publishing read-only data from modules? I guess we maybe could use PVs or XAVPs for that. An ugly way would be to implement RPC in SNMPstats and issue RPC commands internally to fetch data, but that means a lot of serializing that really is not needed as SNMPstats generally fetches one parameter (OID) at a time, not complete sets.
I've added a whole slew of new counters so you can see what is going on at the sub-protocol level. Feel free to add them to SNMP if they will help.
Cool. I will add them.
Note that the frames received and transmitted counters for SIP and MSRP only count frames containing SIP and MSRP messages. So the existing total frames received and transmitted counters will contain larger numbers as they include control frames too.
I'll implement them as counters that can roll around.
I have also added the sub-protocol used to the dump MI command, but not sure that is really useful. The WebSocket MI commands were only really added to help with testing. For example, the dump command won't help much on a system with thousands of active connections - simply too much data.
Right.
The WebSocket module doesn't actually contain any RPC commands at all. Not sure what use they would be for this module anyway.
Also, some of the modparam parameters could be exposed as cfg params - which would make it easier to change them at runtime with sercmd, but also expose them in SNMPstats. I think keepalive_interval and keepalive_timeout are candidates for this.
If you can point me at a clear example of where this done elsewhere I'll be happy to add it.
Look at dispatcher - config.c and dispacher.c. http://sip-router.org/docbook/sip-router/branch/master/cfg_list/cfg_var_list...
That page also gives more examples. I don't see a callback when variables in the config fw changes, so you need to get them with cfg_get before using if I understand it right.
I will experiment and see if I can expose this in the snmp module. I don't see any Dispatcher-related variables in the MIBs, so that needs to be added. Time for me to learn about tables in NET-SNMP and MIBs.
/O
Regards,
Peter
-- Peter Dunkley Technical Director Crocodile RCS Ltd
30 mar 2013 kl. 18:32 skrev "Olle E. Johansson" oej@edvina.net:
Also, some of the modparam parameters could be exposed as cfg params - which would make it easier to change them at runtime with sercmd, but also expose them in SNMPstats. I think keepalive_interval and keepalive_timeout are candidates for this.
If you can point me at a clear example of where this done elsewhere I'll be happy to add it.
Look at dispatcher - config.c and dispacher.c. http://sip-router.org/docbook/sip-router/branch/master/cfg_list/cfg_var_list...
That page also gives more examples. I don't see a callback when variables in the config fw changes, so you need to get them with cfg_get before using if I understand it right.
Looking at the _cfg_def structure there is a callback. I was wrong. This framework could also be used for read-only variables, like "SIP Outbound enabled", "Websockets/SIP enabled", "Websockets/TLS/SIP enabled".
/O
Done. I think.
I don't have a system here to test WebSockets at the moment, but the changes looked pretty straight-forward and it all compiles OK :-)
Can you take a look and tell me if it is what you were thinking? If anyone has any problems with it I'll roll back the changes.
There are two configuration variables, one for keepalive_timeout and one for enabled. This means the keepalive_timeout can be changed live and the WebSocket enabled/disabled state (previously just settable through MI commands) can be changed using the cfg framework.
The keepalive_interval that you suggested is used during module init to set how often the extra processes for sending keep-alives runs. I can't see how to change this once Kamailio has started.
Regards,
Peter
30 mar 2013 kl. 18:32 skrev "Olle E. Johansson" oej@edvina.net:
Also, some of the modparam parameters could be exposed as cfg params - which would make it easier to change them at runtime with sercmd, but also expose them in SNMPstats. I think keepalive_interval and keepalive_timeout are candidates for this.
If you can point me at a clear example of where this done elsewhere I'll be happy to add it.
Look at dispatcher - config.c and dispacher.c. http://sip-router.org/docbook/sip-router/branch/master/cfg_list/cfg_var_list...
That page also gives more examples. I don't see a callback when variables in the config fw changes, so you need to get them with cfg_get before using if I understand it right.
Looking at the _cfg_def structure there is a callback. I was wrong. This framework could also be used for read-only variables, like "SIP Outbound enabled", "Websockets/SIP enabled", "Websockets/TLS/SIP enabled".
/O
30 mar 2013 kl. 21:33 skrev "Peter Dunkley" peter.dunkley@crocodile-rcs.com:
Done. I think.
I don't have a system here to test WebSockets at the moment, but the changes looked pretty straight-forward and it all compiles OK :-)
Can you take a look and tell me if it is what you were thinking? If anyone has any problems with it I'll roll back the changes.
On first look the commit looks exactly like I was thinking. I was just playing with the outbound module to implement a read-only "outbound_enabled" to figure out how to do this. I found the /doc/cfg.txt file very useful in order to understand this framework.
There are two configuration variables, one for keepalive_timeout and one for enabled. This means the keepalive_timeout can be changed live and the WebSocket enabled/disabled state (previously just settable through MI commands) can be changed using the cfg framework.
The keepalive_interval that you suggested is used during module init to set how often the extra processes for sending keep-alives runs. I can't see how to change this once Kamailio has started.
Makes sense.
/O
Regards,
Peter
30 mar 2013 kl. 18:32 skrev "Olle E. Johansson" oej@edvina.net:
Also, some of the modparam parameters could be exposed as cfg params - which would make it easier to change them at runtime with sercmd, but also expose them in SNMPstats. I think keepalive_interval and keepalive_timeout are candidates for this.
If you can point me at a clear example of where this done elsewhere I'll be happy to add it.
Look at dispatcher - config.c and dispacher.c. http://sip-router.org/docbook/sip-router/branch/master/cfg_list/cfg_var_list...
That page also gives more examples. I don't see a callback when variables in the config fw changes, so you need to get them with cfg_get before using if I understand it right.
Looking at the _cfg_def structure there is a callback. I was wrong. This framework could also be used for read-only variables, like "SIP Outbound enabled", "Websockets/SIP enabled", "Websockets/TLS/SIP enabled".
/O
-- Peter Dunkley Technical Director Crocodile RCS Ltd
30 mar 2013 kl. 21:33 skrev "Peter Dunkley" peter.dunkley@crocodile-rcs.com:
Done. I think.
I don't have a system here to test WebSockets at the moment, but the changes looked pretty straight-forward and it all compiles OK :-)
Can you take a look and tell me if it is what you were thinking?
kamcmd> cfg.get websocket keepalive_timeout 180 kamcmd> cfg.get websocket enabled 1
kamcmd> cfg.list websocket: keepalive_timeout websocket: enabled
kamcmd> cfg.help websocket keepalive_timeout Time (in seconds) after which to send a keep-alive on idle WebSocket connections. (parameter type is integer) ----------------------------------------------------
This should be useful in snmpstats. Thanks! I'll work on that soon.
I have a similar patch with "outbound enabled" - ok to commit in your module?
That will be easy to copy to other module, like app_* and dnssec ;-)
Having this functionality helps apps using RPC as well as SNMPstats users. Siremis is one good example. Ovidiu's HTTP framework is another.
Database connections would be another good thing to be able to monitor with SNMP. I think we're on to something here.
- Use a read-only config framework variable to declare a module loaded, initiated and working. - Use other variables for settings that can be changeable during runtime (but not during processing of a single message, which is a cool thing with the config framework). - Use this for exposing (read-only) functionality like "database connected and working"
- Use this for modparams that you allow to change during runtime.
Since there is a read-only flag, I suspect this was part of the design.
What does the rest of the development gang think? Is this something useful - to use the config framework to tell other modules about the state of a module, not just configuration parameters?
If we agree on this, we can add these flags to more modules as we go along.
/O
-
Olle E. Johansson -
Peter Dunkley