[SWMP] Re: faster field messages

john_patterson@us.ibm.com Wed, 29 August 2007 13:37 UTC

Return-path: <swmp-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQNjJ-0007Uh-3a; Wed, 29 Aug 2007 09:37:09 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQNjH-0007UY-J1 for swmp@ietf.org; Wed, 29 Aug 2007 09:37:07 -0400
Received: from e1.ny.us.ibm.com ([32.97.182.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQNjG-00017v-Ug for swmp@ietf.org; Wed, 29 Aug 2007 09:37:07 -0400
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l7TDanAL028004 for <swmp@ietf.org>; Wed, 29 Aug 2007 09:36:49 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l7TDalrA671312 for <swmp@ietf.org>; Wed, 29 Aug 2007 09:36:49 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l7TDalQ5010576 for <swmp@ietf.org>; Wed, 29 Aug 2007 09:36:47 -0400
Received: from internet1.lotus.com (internet1.lotus.com [9.33.9.11]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7TDalbc010533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Aug 2007 09:36:47 -0400
Received: from wtfmail02.edc.lotus.com (wtfmail02.lotus.com [9.33.9.69]) by internet1.lotus.com (8.14.1/8.14.1) with ESMTP id l7TDal3O009018; Wed, 29 Aug 2007 09:36:47 -0400 (EDT)
In-Reply-To: <46CF04CF.7080903@mediamachines.com>
To: "Jay C. Weber" <jweber@mediamachines.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0 August 18, 2005
Message-ID: <OFEC8B3B5C.325A7433-ON85257346.00470B2F-85257346.004AC0D4@lotus.com>
From: john_patterson@us.ibm.com
Date: Wed, 29 Aug 2007 09:37:28 -0400
X-MIMETrack: Serialize by Router on WTFMAIL02/WTF/M/Lotus(Build V703_08192007|August 19, 2007) at 08/29/2007 09:37:30 AM, Serialize complete at 08/29/2007 09:37:30 AM
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Cc: swmp@ietf.org
Subject: [SWMP] Re: faster field messages
X-BeenThere: swmp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of a Simple Wide-area Multiuser-3D Protocol <swmp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/swmp>, <mailto:swmp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/swmp>
List-Post: <mailto:swmp@ietf.org>
List-Help: <mailto:swmp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/swmp>, <mailto:swmp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1286580859=="
Errors-To: swmp-bounces@ietf.org

Jay:

I think I understand the mechanism and I understand that either side of 
the pairwise communication can establish the mapping of an ID to a 
<node,field>.

Perhaps it is a small thing, but in a situation in which one network 
element (say a server) manages the data, it would be helpful if it could 
use the same ID for all the other network elements seeking to use the 
data.  If the other network elements may establish the mapping, then it 
must keep independent mappings for each network element being served.  If, 
on the other hand, we can contrive the protocol, so that the network 
element managing the data establishes the ID mapping, then it could use 
the same mapping for all network elements seeking service.

jfp

"Jay C. Weber" <jweber@mediamachines.com> wrote on 08/24/2007 12:18:23 PM:

> john_patterson@us.ibm.com wrote:
> F)  The use of the fieldId on the SET message as a way to allow 
> faster field references seemed to require modification.  For one 
> thing, it did not seem right that the name/id association was being 
> defined by the requesting network element rather than the network 
> element controlling the state.
> It's really about this:  element A needs to specify a <node,field> 
> in a message to element B.  If A sends B a number of such messages, 
> it's worth setting up a shorthand for that pair.  Thus my SWMP 
> design was to add a message parameter to SET, a non-negative integer
> fieldId, that when non-zero means "if I use this fieldId in the 
> future it means this <node,field> pair".  And I created a SETF 
> message that uses the fieldId.  Thus one SET message would be 
> followed by many SETF messages, the advantage being that SETF 
> messages are much shorter.
> 
> It doesn't matter what the architectural roles are of A and B, it's 
> just a bilateral mechanism to create a shorthand, and it makes sense
> to me that the element that coins the <node,field> pair is the one 
> to coin the shorthand for it.
> 
> jay
> -- 
> Jay C. Weber, Ph.D. 
> CTO, Media Machines Inc. 
> 650-279-2311 
_______________________________________________
SWMP mailing list
SWMP@ietf.org
https://www1.ietf.org/mailman/listinfo/swmp