Proxy Module does not work after restart of the remote agents

Hi

During my proxy extension I encountered the following behaviour (of the
original proxy module), which I don't understand


my stetup:

- one agent simply acting as a proxy (for simplicity just proxiing one OID
to another agent)

- a second agent B, which gets the requests from the proxy.

I start the proxy agent and the 'normal' agent.

A GET request to the proxy gets forwarded and answered by the agent B
correctly.

When I now stop the agent B and again issue a GET command to the proxy, I
receive a timeout as expected.

NOW:

After restarting the Agent B again, proxying does not work anymore. From the
debug output of the proxy I can see, that the forwarded packets all result
in a timeout as if the Agent B would not be alive (But he is! Issuing the
GET command directly to agent B works).

Is the 'session' to the Agent B somehow not active anymore? Did I miss
something?


Interestingly, on the first start, it does not matter, if I start the proxy
or the agent as first program...

Thanks for any help

Boris




2010/5/20 Dave Shield <[email protected]>

> On 20 May 2010 11:10, Boris Zweimueller <[email protected]> wrote:
> > If you don't mind I have just one more quetsion regarding Traps.
> >
> > I read that they are 'unreliable'. This is ment regarding the transport
> > protocol, is this correct?
>
> No.
> They are "unreliable" because they are not acknowledged by the
> receiving station.
> Inform requests are "reliable" because they are acknowledged.
>   (Though the sender has no idea what the receiver actually did with
> this notification!)
>
> > If I use TCP, then they will be reliable.
>
> No - see above.
>
>
> > I plan to use them for asynchronous communication from the parallel
> agents to the
> > master agent.
>
> Probably not a good idea.
>
>
>
> > - e.g. a getter to check for the computation to be finished.
> > - a aspecial implementation for the SET of a specific value which starts
> the
> > computation and finally stores the result (ok/notok) in the variable.
> after
> > that it can be read with the corresponding GET.
>
> That would be a more sensible approach.
> I would suggest four possible values for this object:
>
>   ok
>   notok
>   calculating
>   startCalculation
>
> with the first three being returned by a GET request,
> and the fourth being the only valid SET assignment.
>
> Dave
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Net-snmp-users mailing list
> [email protected]
> Please see the following page to unsubscribe or change other options:
> https://lists.sourceforge.net/lists/listinfo/net-snmp-users
>

------------------------------------------------------------------------------

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users