[AGENT++] SNMP++.NET

[Frank Fock]

Hi Marek,

I have spent a few minutes to take a look at your .NET wrappers.
Looks really nice! 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.

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
>
>  
>