[SNMP4J] (no subject)

Angel Angelov angel at sayrix.com
Wed Nov 9 22:18:27 CET 2005


No, Im using v1.6b1.
Is not v1.6a minor than v1.6b1?

--Anguel


Frank Fock wrote:

> Hi Angel,
>
> Are you using v1.6a? This version includes a fix regarding this issue.
>
> Best regards,
> Frank
>
> Angel Angelov wrote:
>
>> Hi Frank,
>> thanks for the advise. I will set the request id in this way.
>> But this don't solve the problem described in the previous mail.
>>
>> I think, the problem is because the PDU class uses a Integer32 (based 
>> on the java int type) as a requestID.
>> As you know the java int type is signed 32 bit.
>> Maybe there are some problems by storing the 32 bit value to the int 
>> variable.
>>
>> In the example bellow, the request id 0x87c63fd7  should be 
>> translated in to negative java int.
>> And the negative int should be serialized to 0x87c63fd7 through the 
>> Integer32 class, but it is serialized to 0x3f9119cf
>>
>> P.S. Sorry, I forgot to put subject on this thread in my first mail. :-(
>>
>> Regards,
>> Angel
>>
>>
>> Frank Fock wrote:
>>
>>> Hi Angel,
>>>
>>> using
>>> responsePDU.setRequestID(new 
>>> Integer32(requestPDU.getRequestID().getValue());
>>> would be more safe in a multi-threaded environment.
>>>
>>> Best regards,
>>> Frank
>>>
>>> Angel Angelov wrote:
>>>
>>>> Hi Guys,
>>>> I'm new to this list.
>>>> At first I want to thank you for the great snmp library. :-)
>>>>
>>>> I have some problems implementing the CommandResponder interface.
>>>> When I receive GET/GETNEXT PDU, I create a RESPONSE PDU.
>>>> I set the to the response pdu the same request id as the request 
>>>> pdu by:
>>>> responsePDU.setRequestID(requestPDU.getRequestID());
>>>>
>>>> Some times this source code sends back a request id different from 
>>>> the incoming request id!
>>>> Here is an example:
>>>> GET request ID  -> 0x87c63fd7
>>>> RESPONSE request ID -> 0x3f9119cf
>>>> I cached the data by sniffing my udp packets on the network.
>>>>
>>>> And as you know, if the request id's are not matching, the agent 
>>>> ignore them....
>>>>
>>>> Do somebody have a suggestion for a work around for the problem?
>>>> Thanks.
>>>>
>>>> Regards,
>>>> Angel             _______________________________________________
>>>> SNMP4J mailing list
>>>> SNMP4J at agentpp.org
>>>> http://lists.agentpp.org/mailman/listinfo/snmp4j
>>>>
>>>>
>>>>  
>>>>
>>>
>>>
>>
>>
>
>



More information about the SNMP4J mailing list