[SNMP4J] Serializing a session

Kevin J. Schmidt kjschmidt at gmail.com
Thu Mar 24 17:24:23 CET 2005


Here's how things flow now:


My app ---> SNMP4j ---> [network] ---> SNMP4j ---> trap receiver app

I want to cut out the network part of it (for unit testing only) but
still be able to create an SNMP session, add variable bindings, "send"
the trap, and have the other side (trap receiver) get the trap with
having to sit and wait for data to hit its trap port.

I was wondering if something like this could be done:

My app (thread 1) creates a trap and somehow serializes it and puts it
into a synchronized data struct.

The trap receiver app (thread 2) waits for the data to be placed in
the synced data structure, gets the serialized blob, unmarshalls it,
and processes it as if it had received it on the wire.

I'm not sure if I clarified what I want to do or not. :-)

On Wed, 23 Mar 2005 20:30:22 +0100, Frank Fock <fock at agentpp.com> wrote:
> Hi Kevin,
> 
> Are you thinking about a RMI-TransportMapping? A SNMP4J Snmp instance
> cannot be serialized because the contained TransportMappings use local
> resources
> like UDP or TCP ports. But you may implement a RMITransportMapping
> that sends/receives SNMP messages across a RMI over TCP tunnel.
> But I do not see why this could be advantageous
> <se?lp=ende&p=/Mn4k.&search=advantageous>?
> 
> Best regards,
> Frank
> 
> Kevin J. Schmidt wrote:
> 
> >I've written an application which sends SNMP notifications and traps.
> >I have created various unit tests (via JUnit) which create mock SNMP
> >listeners (using SNMP4j)  to wait for traps to come in from my
> >application code.
> >
> >Instead of having one or more receivers sitting on a port (both sender
> >and receiver are on the same box), can I some how serialize the Snmp
> >session from the sender and hand it off (via synchronization and
> >shared data struct) to the receiver and let it "replay" the serialized
> >object?
> >
> >Thanks,
> >
> >
> 
> 


-- 
Kevin J. Schmidt
<kjschmidt at gmail.com>



More information about the SNMP4J mailing list