Well, that explains asynchronous, but why single session?
Here is my understanding: The Traditional API manages a global list
for all sessions, and session operations are not thread-safe because
the global session list does not have locks. The Single API makes
operations thread-safe by using a th
Den 21-07-2010 21:53, Brendan Tauras skrev:
> Now you're probably thinking why do asynchronous Single API requests.
> I have been tasked to write a snmp monitoring program. It must
> request different OIDs at different time intervals, and one request
> cannot hold up another (e.g. walks can take a
What are you trying to do in the callback?
I am trying to continue a walk that uses bulk requests.
Why do you need access to the opaque session structure?
I need to continue the bulk walk request. The original call used the
Single API via snmp_sess_async_send(), so I understand that I must use
th
On 20 July 2010 17:54, Brendan Tauras wrote:
> I am getting the internal snmp_session pointer from the Single API.
> When I use snmp_sess_async_send(), my callback function gets
> a snmp_session pointer instead of an opaque session pointer.
OK - I see where this is coming from.
> Am I doing so
Thank you for your help. I must be doing something wrong because I am
getting the internal snmp_session pointer from the Single API. When I
use snmp_sess_async_send(), my callback function gets a snmp_session
pointer instead of an opaque session pointer. I have compile errors
If I use any other
On 20 July 2010 15:54, Brendan Tauras wrote:
> Is there a way to get the opaque session pointer (struct session_list
> * typecasted as a void *) from the regular session pointer (struct
> snmp_session *) when using the Single API?
I don't believe so, no.
If you're using the Single Session API, t
