[SNMP4J] (no subject)

[Angel Angelov]

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