30 Mar
2013
30 Mar
'13
12:07 p.m.
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. :-)
30 Mar
30 Mar
2:29 p.m.
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
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
7:32 p.m.
30 mar 2013 kl. 13:29 skrev "Peter Dunkley"
<peter.dunkley(a)crocodile-rcs.com>om>:
Hello Olle,
Cool. I
will add them.
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'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.
Look at dispatcher - config.c and dispacher.c.
http://sip-router.org/docbook/sip-router/branch/master/cfg_list/cfg_var_lis…
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
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
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
7:53 p.m.
30 mar 2013 kl. 18:32 skrev "Olle E. Johansson" <oej(a)edvina.net>et>:
Look at dispatcher - config.c and dispacher.c.
http://sip-router.org/docbook/sip-router/branch/master/cfg_list/cfg_var_lis…
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
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.
10:33 p.m.
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(a)edvina.net>et>:
Look at dispatcher - config.c and dispacher.c.
http://sip-router.org/docbook/sip-router/branch/master/cfg_list/cfg_var_lis…
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
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.
31 Mar
31 Mar
12:40 p.m.
30 mar 2013 kl. 21:33 skrev "Peter Dunkley"
<peter.dunkley(a)crocodile-rcs.com>om>:
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(a)edvina.net>et>:
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 > 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_lis…
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.
3:28 p.m.
30 mar 2013 kl. 21:33 skrev "Peter Dunkley"
<peter.dunkley(a)crocodile-rcs.com>om>:
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
4254
days inactive
4255
days old
6 comments
2 participants
participants (2)
-
Olle E. Johansson -
Peter Dunkley