[AGENT++] SNMP++.NET

[Marek Malowidzki]

> Hi Marek,
>
> I have spent a few minutes to take a look at your .NET wrappers.
> Looks really nice!

Nice to hear it.

> Until now, only noticed one possibly problematic
> issue:
>
> In .NET the String class supports multi-byte characters as they are
> supported by the Java String class, right? Thus, characters with a
> hex value >= 0x80 (highest bit set) indicate a multi-byte character.
> So when using String instead of OctetString, this might cause problems.

Thanks for pointing this out. In fact, what really causes a problem are null
(0x00) characters, which denote end-of-string in C/C++ but are perfectly
legal in String .NET or Java (Unicode). Thus, I needed to fix the
implementation in a number of places. Characters with values above 0xff will
have its values simply truncated to the lower byte.

Marek


>
> Best regards,
> Frank
>
> Marek Malowidzki wrote:
>
> >>>Hi Marek,
> >>>
> >>>I would like, of course, take a look at your implementation. Do you
plan
> >>>to place the code on your web site once you have released it?
> >>>
> >>>
> >>Yes, of course, it will be made public. The current implementation is
> >>available at
> >>
> >>http://republika.pl/maom_onet/snmpppdotnet/
> >>
> >>
> >
> >Well, it looks like you are busy with SNMP4J. Of course, I do not try to
> >hurry you but just would like to add that I have compiled the component
> >against 3.2.10 and was able to get rid of the ugly '(Snmp*) 0xffffffff'
> >supplied as the first argument for v3MP (which would probably caused
crash
> >on the reception of INFORM, as I guess).
> >
> >There was also some more effort and small improvements:
> >- ordered signed/unsigned mess and now all Length/Count's are UInt32
> >- added helper properties for "composed of" objects (e.g., the Oids
property
> >that returns sub-ids for a given OBJECT IDENTIFIER)
> >- added iterators for "composed of" objects (Oid, Pdu, OctetStr, etc.),
> >which allows foreach() statement to be used in a convenient way
> >- slightly improved the manager demo program which now can start multiple
> >treads for testing purposes.
> >
> >The sources at the above location have been updated. I believe that there
is
> >no SNMPv3 implementation for .NET (at least, not an open-source one, or
at
> >least, I am not aware of any), so this could be an interesting
contribution.
> >Of course, there is still some work left, e.g. the documentation and some
> >missing stuff (like IPX addresses).
> >
> >I would also like to pay your attention again to Pdu::set_notify_id() as
it
> >still uses 'const Oid id' instead of 'const Oid &id' - not a big deal but
> >anyway worth being corrected. (I am not sure if it was legal for a C++
> >compiler to perform some optimization since the constructors could have
some
> >side effects, e.g. on global variables).
> >
> >Marek
> >
> >following files are present:
> >
> >
> >>MConversion.cpp
> >>MConversion.h
> >>MTypes.h
> >>MLock.h
> >>auto_array_ptr.h
> >>
> >>These are various helper files, mainly for memory management and types
> >>conversion.
> >>
> >>MSnmpComp.cpp
> >>
> >>This is the main component code. Please have a look at the info in the
> >>header (just after the copyrights). In this note, I am trying to explain
> >>
> >>
> >the
> >
> >
> >>most important decisions concerning the current implementation.
> >>
> >>MSnmpCompExample.cs
> >>MSnmpManager.cs
> >>
> >>The first file is a simple example that shows the "look & feel" of the
> >>implementation. The "manager" file is a command line utility that allows
> >>
> >>
> >to
> >
> >
> >>issue get/next/bulk/walk operations. This is, in fact, rewritten snmpSet
> >>example from your distribution.
> >>
> >>The component has been checked and it seems to work - we are able to use
> >>
> >>
> >all
> >
> >
> >>kinds of operations, including SNMPv3. However, I admit that the
> >>implementation lacks thorough tests against every piece of code. I do
not
> >>expect anyone to do beta testing - I would just like to discuss the
design
> >>(the API), and we will perform the tests when it becomes stable. That
> >>
> >>
> >said,
> >
> >
> >>I think that most of the code is just thin wrapping around SNMP++ and
our
> >>results are encouraging - we have performed some stress tests (with
the -n
> >>option set to a large value and locally running agent that allows to
> >>perform, on my slow PC, about 100 SNMP calls/second) and we did not
notice
> >>any memory problems; from time to time, the memory usage descreases, as
> >>
> >>
> >the
> >
> >
> >>system monitor shows. Looks like garbage collecting works sufficiently
> >>
> >>
> >well
> >
> >
> >>also for the unmanaged memory (that is, the unmanaged memory is
reclaimed
> >>when finalizers are invoked on managed objects being collected).
> >>
> >>Best regards,
> >>
> >>Marek
> >>
> >>_______________________________________________
> >>AGENTPP mailing list
> >>AGENTPP at agentpp.org
> >>http://agentpp.org/mailman/listinfo/agentpp
> >>
> >>
> >
> >_______________________________________________
> >AGENTPP mailing list
> >AGENTPP at agentpp.org
> >http://agentpp.org/mailman/listinfo/agentpp
> >
> >
> >
>
>
>