Subject: [Agentx] Benefit of multiple sessions per sub-agent connection

From: Julian Scheid <[email-masked]>
Date: Fri, 2 Jul 2010 01:07:56 +1200

Could someone give a practical example of when a sub-agent would want
to open more than one session per connection?

I've written a sub-agent implementation whose code and API would be
simpler if it would limit users to a single session per connection,
and I am wondering what benefits it would deprive them of by doing so.
As you might guess, I'm hard pressed to come up with use cases myself
-- I must be missing something.

I'm not exactly an SNMP expert, my apologies if this is a silly question.

Thanks in advance.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 1 Jul 2010 14:42:31 -0700

Hi -

> From: "Julian Scheid" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, July 01, 2010 6:07 AM
> Subject: [Agentx] Benefit of multiple sessions per sub-agent connection
>

Examples that come to mind are when the subagent is functioning as a
gateway to some other subagent protocol, bridging to a transport
protocol not supported by the master agent implementation, or both.
I suppose it could come in handy with a connectionless subagent transport,
but that seems to me to be a bit of a stretch.  There might be other uses,
but I've been away from this stuff for a long time.
 
> simpler if it would limit users to a single session per connection,

There really isn't much reason to expose session ID in a subagent API.
Assuming you have some kind of constructor that returns a session object,
the session ID would be private data that only the library, and not the
user code, would ever have to llok at.

> I'm not exactly an SNMP expert, my apologies if this is a silly question.

Not silly at all.  As I recall, this was a "borderline" feature of the protocol,
dating from a time when lots of things other than AgentX were in use,
and the need to be able to build ways to support legacy subagents was
a real concern.

Randy

---

From: Julian Scheid <[email-masked]>
Date: Fri, 2 Jul 2010 11:36:10 +1200

Hi Randy,

thanks for your reply.

> but I've been away from this stuff for a long time.

This makes sense. Since my implementation won't have to be used to
build a bridge or such, I think I'll implicitly open a singleton
session and hide the details from the user.

> user code, would ever have to llok at.

Sure, but even when hiding the ID, exposing a session object
complicates the API slightly - now people have to interact with two
objects rather than one.  There'll be an additional call to create the
session and users will have to worry about things like the session
object becoming invalid when the connection is closed. Not that big of
a deal but if those details can be hidden, all the better.

> and the need to be able to build ways to support legacy subagents was

Thanks for explaining the rationale, much appreciated.

Julian

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 1 Jul 2010 21:13:16 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, July 01, 2010 4:36 PM
> Subject: Re: [Agentx] Benefit of multiple sessions per sub-agent connection
...
> a deal but if those details can be hidden, all the better.

Depending on your environment, you may want to consider how you
handle multiple transports.  Also, if you're working with a select() paradigm
in an event-driven system, for example, there's good reason to separate
the notion of connection from the notion of session.

Randy