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

Julian Scheid <julians37@googlemail.com> Thu, 01 July 2010 23:36 UTC

Return-Path: <julians37@googlemail.com>
X-Original-To: agentx@core3.amsl.com
Delivered-To: agentx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C469828C107 for <agentx@core3.amsl.com>; Thu, 1 Jul 2010 16:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.467
X-Spam-Level:
X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+eBculhZEBk for <agentx@core3.amsl.com>; Thu, 1 Jul 2010 16:36:04 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id A159528C105 for <agentx@ietf.org>; Thu, 1 Jul 2010 16:36:04 -0700 (PDT)
Received: by vws14 with SMTP id 14so1378268vws.31 for <agentx@ietf.org>; Thu, 01 Jul 2010 16:36:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mB7/LkpaS9zeHZ9HRSQmN6W8wMbYwFl89HnHAvP09CI=; b=aCgx/be29MqbFk1hKd+TNE+T4fRwa3/RNVVlLELDeW8UFmT6QGrW9CyEj/BdH0MpFF Y3q+uIhhe7BqiQnTwn+wNmKiGNqK8/XLXsH5F8rBb34DNW4jwvawa7FI6lI13RIfj12k KunMHv2/dtVmiTubS5NXSm9aZ3E/bieA/N1EY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xaa+GYr5i9755Z/pDmwx+Jwk6OzRXCdQHoXhG2RJNnJUGcs2/rxpa1kzyC0N1VzjOv fxQ30XIzwcf1srbT5CCiC/1JqHoGirQSGGUOpbT3l7b6hVls9LSB9zllUKVw447HUdKY 1WG5Qd5ZumnNZw81ECEim8KnPIvT8og8pt3XU=
MIME-Version: 1.0
Received: by 10.229.248.197 with SMTP id mh5mr165148qcb.113.1278027371288; Thu, 01 Jul 2010 16:36:11 -0700 (PDT)
Received: by 10.229.100.70 with HTTP; Thu, 1 Jul 2010 16:36:10 -0700 (PDT)
In-Reply-To: <001601cb1966$500d5240$6801a8c0@oemcomputer>
References: <AANLkTim0hJMvTOz1gZUXcnFIt73A6RGm8CgehPxKB7NS@mail.gmail.com> <001601cb1966$500d5240$6801a8c0@oemcomputer>
Date: Fri, 2 Jul 2010 11:36:10 +1200
Message-ID: <AANLkTimgHjn3id6jbmaOBXKfnvkBSgdCzxLbuuag5tD_@mail.gmail.com>
From: Julian Scheid <julians37@googlemail.com>
To: Randy Presuhn <randy_presuhn@mindspring.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: agentx@ietf.org
Subject: Re: [Agentx] Benefit of multiple sessions per sub-agent connection
X-BeenThere: agentx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SNMP Agent Extensibility <agentx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/agentx>, <mailto:agentx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/agentx>
List-Post: <mailto:agentx@ietf.org>
List-Help: <mailto:agentx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/agentx>, <mailto:agentx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jul 2010 23:36:05 -0000

Hi Randy,

thanks for your reply.

On Fri, Jul 2, 2010 at 9:42 AM, Randy Presuhn
<randy_presuhn@mindspring.com> wrote:
> 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.

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.

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

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.

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

Thanks for explaining the rationale, much appreciated.

Julian