Re: A MIB file dilemma
The file system scenario was the closest example I could think of.
The device I am creating a MIB file for has ALOT of parameters which is
organized in a hierarchy must like a file system. Each node in the path can
have a few scalars(parameters), but most of them are at the end of a path (a
subsystem).
My application running against a test system created a MIB file with almost
5000 scalars and aprox 500 groups.
According to the SMIv2 (RFC 2578) descriptor names must be unique and mnemonic.
Using a hash is not exactly very mnemonic.
/Sverre
- Original Message -
Fra: Heiko Gerstung he...@am-anger-1.de
Til: net-snmp-users@lists.sourceforge.net
Sendt: 24. oktober 2012 16:00:25
Emne: Re: A MIB file dilemma
On 24.10.2012 14:07, Sverre Moe wrote:
I have come up with the following hack for names over 64 characters. I'm not
sure if this hack is a very good solution.
Truncate in the middle with the number of characters over 64 (+2) and replace
it with -.
std::string tmp_string = name;
const int length = tmp_string.length();
if (length 64) {
const int half = length / 2; //We truncate in the middle.
const int numberOff = (length - 64) + 2; //The number of characters to
truncate.
const std::string dash = -;
tmp_string = tmp_string.replace(half, numberOff, dash);
}
Sverre,
the stuff you seem to want to do with a MIB scares the hell out of me ;-) ...
Not sure what you want to achieve with that
(creating an SNMP file system). However, maybe you should take the MD5 hash of
the full path (echo $FILENAME | md5sum) and
use it as the name of the object and (for better readability) add a comment
-- this is file /etc/hosts -- or something
similar that helps you to find out which object is which file ...
Again: for all the possible things that I could come up with as a reason why
you are doing this, I would see a better
(non-MIB abusing :-)) alternative. But: what do I know :-)
Regards,
Heiko
P.S.: ...
CONFIDENTIALITY
This e-mail and any attachment contain KONGSBERG information which may be
proprietary, confidential or subject to export regulations, and is only meant
for the intended recipient(s). Any disclosure, copying, distribution or use
is
prohibited, if not otherwise explicitly agreed with KONGSBERG. If received in
error, please delete it immediately from your system and notify the sender
properly.
[insert rant about privacy disclaimers in mailing list / newsletter posts here]
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
CONFIDENTIALITY
This e-mail and any attachment contain KONGSBERG information which may be
proprietary, confidential or subject to export regulations, and is only meant
for the intended recipient(s). Any disclosure, copying, distribution or use is
prohibited, if not otherwise explicitly agreed with KONGSBERG. If received in
error, please delete it immediately from your system and notify the sender
properly.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Re: A MIB file dilemma
Hi Sverre,
On 25.10.2012 08:50, Sverre Moe wrote:
The file system scenario was the closest example I could think of.
The device I am creating a MIB file for has ALOT of parameters which is
organized in a hierarchy must like a file system. Each node in the path can
have a few scalars(parameters), but most of them are at the end of a path (a
subsystem).
I see, thanks for the explanation.
My application running against a test system created a MIB file with almost
5000 scalars and aprox 500 groups.
OK.
According to the SMIv2 (RFC 2578) descriptor names must be unique and
mnemonic. Using a hash is not exactly very mnemonic.
I know. But since it seems that you yourself cannot come up with 5000 unique
and mnemonic names (at least not
programmatically/automatically) while being limited to 64 chars, a hash at
least meets the unique requirement.
Regards,
Heiko
/Sverre
- Original Message -
Fra: Heiko Gerstung he...@am-anger-1.de
Til: net-snmp-users@lists.sourceforge.net
Sendt: 24. oktober 2012 16:00:25
Emne: Re: A MIB file dilemma
On 24.10.2012 14:07, Sverre Moe wrote:
I have come up with the following hack for names over 64 characters. I'm not
sure if this hack is a very good solution.
Truncate in the middle with the number of characters over 64 (+2) and
replace it with -.
std::string tmp_string = name;
const int length = tmp_string.length();
if (length 64) {
const int half = length / 2; //We truncate in the middle.
const int numberOff = (length - 64) + 2; //The number of characters to
truncate.
const std::string dash = -;
tmp_string = tmp_string.replace(half, numberOff, dash);
}
Sverre,
the stuff you seem to want to do with a MIB scares the hell out of me ;-) ...
Not sure what you want to achieve with that
(creating an SNMP file system). However, maybe you should take the MD5 hash
of the full path (echo $FILENAME | md5sum) and
use it as the name of the object and (for better readability) add a
comment -- this is file /etc/hosts -- or something
similar that helps you to find out which object is which file ...
Again: for all the possible things that I could come up with as a reason why
you are doing this, I would see a better
(non-MIB abusing :-)) alternative. But: what do I know :-)
Regards,
Heiko
P.S.: ...
CONFIDENTIALITY
This e-mail and any attachment contain KONGSBERG information which may be
proprietary, confidential or subject to export regulations, and is only
meant
for the intended recipient(s). Any disclosure, copying, distribution or use
is
prohibited, if not otherwise explicitly agreed with KONGSBERG. If received
in
error, please delete it immediately from your system and notify the sender
properly.
[insert rant about privacy disclaimers in mailing list / newsletter posts
here]
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
CONFIDENTIALITY
This e-mail and any attachment contain KONGSBERG information which may be
proprietary, confidential or subject to export regulations, and is only meant
for the intended recipient(s). Any disclosure, copying, distribution or use
is
prohibited, if not otherwise explicitly agreed with KONGSBERG. If received in
error, please delete it immediately from your system and notify the sender
properly.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Re: A MIB file dilemma
On 25 October 2012 07:50, Sverre Moe sve...@spacetec.no wrote:
The file system scenario was the closest example I could think of.
The device I am creating a MIB file for has ALOT of parameters
which is organized in a hierarchy must like a file system. Each node
in the path can have a few scalars(parameters), but most of them
are at the end of a path (a subsystem).
Typically how deep is this hierarchy?
How meaningful are the individual names?
How _long_ are the individual names?
My application running against a test system created a MIB file with almost
5000 scalars and aprox 500 groups.
According to the SMIv2 (RFC 2578) descriptor names must be unique and
mnemonic. Using a hash is not exactly very mnemonic.
You could always try a combination of both names and hash values.
Given a path such as
/one/two/three/four/five/six/seven/node
possibilities for the final MIB object name might include:
{hash}-node(hash of directory path)
one-{hash}-node (use root in full)
six-seven-{hash}-node (use selected directories in full)
ottffss-{hash}-node (use initials of directories)
ottff-six-seven-{hash}-node (use initials plus selected directories)
one-ttffs-seven-{hash}-node (ditto)
In each case, the hash would be probably be calculated over
/one/two/three/four/five/six/seven in order to keep related scalars together.
You know what the path heirarchy actually looks like,
so are best positioned to decide which elements are best
taken in full, which can be taken using initials, and which
omitted altogether.
But that should give you some ideas to work with.
Dave
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Re: A MIB file dilemma
Not very deep. Each system is different, but I don't think more than 5-8
levels.
Individual names can be from 5 to 20 characters long. Also since some paths can
have either status, config, cmd(command) I prefix with these strings on the
scalar names (which adds to build up length of characters).
I'll look into using hash in the descriptor name, in part or in full.
/Sverre
- Original Message -
Fra: Dave Shield d.t.shi...@liverpool.ac.uk
Til: Sverre Moe sve...@spacetec.no
Kopi: Heiko Gerstung he...@am-anger-1.de,
net-snmp-users@lists.sourceforge.net
Sendt: 25. oktober 2012 09:32:26
Emne: Re: A MIB file dilemma
On 25 October 2012 07:50, Sverre Moe sve...@spacetec.no wrote:
The file system scenario was the closest example I could think of.
The device I am creating a MIB file for has ALOT of parameters
which is organized in a hierarchy must like a file system. Each node
in the path can have a few scalars(parameters), but most of them
are at the end of a path (a subsystem).
Typically how deep is this hierarchy?
How meaningful are the individual names?
How _long_ are the individual names?
My application running against a test system created a MIB file with almost
5000 scalars and aprox 500 groups.
According to the SMIv2 (RFC 2578) descriptor names must be unique and
mnemonic. Using a hash is not exactly very mnemonic.
You could always try a combination of both names and hash values.
Given a path such as
/one/two/three/four/five/six/seven/node
possibilities for the final MIB object name might include:
{hash}-node (hash of directory path)
one-{hash}-node (use root in full)
six-seven-{hash}-node (use selected directories in full)
ottffss-{hash}-node (use initials of directories)
ottff-six-seven-{hash}-node (use initials plus selected directories)
one-ttffs-seven-{hash}-node (ditto)
In each case, the hash would be probably be calculated over
/one/two/three/four/five/six/seven in order to keep related scalars together.
You know what the path heirarchy actually looks like,
so are best positioned to decide which elements are best
taken in full, which can be taken using initials, and which
omitted altogether.
But that should give you some ideas to work with.
Dave
CONFIDENTIALITY
This e-mail and any attachment contain KONGSBERG information which may be
proprietary, confidential or subject to export regulations, and is only meant
for the intended recipient(s). Any disclosure, copying, distribution or use is
prohibited, if not otherwise explicitly agreed with KONGSBERG. If received in
error, please delete it immediately from your system and notify the sender
properly.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Re: A MIB file dilemma
On 24.10.2012 14:07, Sverre Moe wrote:
I have come up with the following hack for names over 64 characters. I'm not
sure if this hack is a very good solution.
Truncate in the middle with the number of characters over 64 (+2) and replace
it with -.
std::string tmp_string = name;
const int length = tmp_string.length();
if (length 64) {
const int half = length / 2; //We truncate in the middle.
const int numberOff = (length - 64) + 2; //The number of characters to
truncate.
const std::string dash = -;
tmp_string = tmp_string.replace(half, numberOff, dash);
}
Sverre,
the stuff you seem to want to do with a MIB scares the hell out of me ;-) ...
Not sure what you want to achieve with that
(creating an SNMP file system). However, maybe you should take the MD5 hash of
the full path (echo $FILENAME | md5sum) and
use it as the name of the object and (for better readability) add a comment
-- this is file /etc/hosts -- or something
similar that helps you to find out which object is which file ...
Again: for all the possible things that I could come up with as a reason why
you are doing this, I would see a better
(non-MIB abusing :-)) alternative. But: what do I know :-)
Regards,
Heiko
P.S.: ...
CONFIDENTIALITY
This e-mail and any attachment contain KONGSBERG information which may be
proprietary, confidential or subject to export regulations, and is only meant
for the intended recipient(s). Any disclosure, copying, distribution or use is
prohibited, if not otherwise explicitly agreed with KONGSBERG. If received in
error, please delete it immediately from your system and notify the sender
properly.
[insert rant about privacy disclaimers in mailing list / newsletter posts here]
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
