From julians37@googlemail.com Thu Jul 1 06:07:53 2010 Return-Path: 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 4162A3A6869 for ; Thu, 1 Jul 2010 06:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.365 X-Spam-Level: X-Spam-Status: No, score=-1.365 tagged_above=-999 required=5 tests=[AWL=0.612, 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 92ZxhQ46F4VQ for ; Thu, 1 Jul 2010 06:07:49 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 0105E3A680B for ; Thu, 1 Jul 2010 06:07:48 -0700 (PDT) Received: by gyh3 with SMTP id 3so1090367gyh.31 for ; Thu, 01 Jul 2010 06:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=NunBO/0h58aeIkuJtcIzSv/OZdLowhhjVGJkJ5cJKAY=; b=J4Q0PAT2TWQc2VvdOwWerRWHmGMLQU7DCRTeVNCv5rI+8o2GOSM0dumZIKcwaht98x AtagtTD89LUjLaXydPdIKrDkJVMygv8+8jdOtuArL8DmjM886cAYVurYM5vRUv/EdKf0 /880F7L9xWyYU1M6EqcGnk37SySIYWFdT4xMQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=d1a5I+vg3lWeYPqsEvxxXEZYI/BsT4U+NQE9+X+z9Qm/HhrAkczq2MlRPeiIPiA3px V1GSltrJXKVC+XdPQZ4h0zLfdbTT1aDYjb2jiM/9/NgvqtvthjpaGoQe+omQH0vLWclC EnwUaTrwYl1hJDTCdMhVIe1BvXhH4CpIZlFDk= MIME-Version: 1.0 Received: by 10.229.222.139 with SMTP id ig11mr6171541qcb.176.1277989676448; Thu, 01 Jul 2010 06:07:56 -0700 (PDT) Received: by 10.229.100.70 with HTTP; Thu, 1 Jul 2010 06:07:56 -0700 (PDT) Date: Fri, 2 Jul 2010 01:07:56 +1200 Message-ID: From: Julian Scheid To: agentx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 13:07:53 -0000 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@mindspring.com Thu Jul 1 14:40:25 2010 Return-Path: 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 761D43A6948 for ; Thu, 1 Jul 2010 14:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.158 X-Spam-Level: X-Spam-Status: No, score=0.158 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_50=0.001] 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 PfE9Hwow+PQi for ; Thu, 1 Jul 2010 14:40:24 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 3E7D43A68BB for ; Thu, 1 Jul 2010 14:40:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VtzkAmnfxy2kDjcRLV1t4fl03BtYPghuaBkKAU5YBuhRhCY+ICdz42hmx485DMPK; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.48.72] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OURUp-0001oC-5t for agentx@ietf.org; Thu, 01 Jul 2010 17:40:35 -0400 Message-ID: <001601cb1966$500d5240$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Thu, 1 Jul 2010 14:42:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780356819e8eb4c795ae07a6ee960092aa2ce350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.48.72 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 21:40:25 -0000 Hi - > From: "Julian Scheid" > To: > Sent: Thursday, July 01, 2010 6:07 AM > Subject: [Agentx] Benefit of multiple sessions per sub-agent connection > > Could someone give a practical example of when a sub-agent would want > to open more than one session per 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. > 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, 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. > 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. 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 julians37@googlemail.com Thu Jul 1 16:36:05 2010 Return-Path: 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 ; 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 ; 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 ; Thu, 1 Jul 2010 16:36:04 -0700 (PDT) Received: by vws14 with SMTP id 14so1378268vws.31 for ; 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: <001601cb1966$500d5240$6801a8c0@oemcomputer> Date: Fri, 2 Jul 2010 11:36:10 +1200 Message-ID: From: Julian Scheid To: Randy Presuhn 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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. =A0There might be other us= es, > 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. =A0As 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 From randy_presuhn@mindspring.com Thu Jul 1 21:12:14 2010 Return-Path: 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 B77993A6821 for ; Thu, 1 Jul 2010 21:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_20=-0.74] 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 eBfxeLoVwCc4 for ; Thu, 1 Jul 2010 21:12:12 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 80E3A3A6806 for ; Thu, 1 Jul 2010 21:12:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=SC1F05Ynt9Q3O83+hnwLe2BTY85HttFUlAd6F3LBYOLxg0Ehv8mhrQZUdGeZRO19; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.48.72] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OUXbn-0000Am-4w for agentx@ietf.org; Fri, 02 Jul 2010 00:12:11 -0400 Message-ID: <000601cb199c$f5e96f60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001601cb1966$500d5240$6801a8c0@oemcomputer> Date: Thu, 1 Jul 2010 21:13:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035cdabac62523e08aa7dfcfb7f58818a35350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.48.72 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 04:12:14 -0000 Hi - > From: "Julian Scheid" > To: "Randy Presuhn" > Cc: > Sent: Thursday, July 01, 2010 4:36 PM > Subject: Re: [Agentx] Benefit of multiple sessions per sub-agent connection ... > 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. 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