RE: [SWMP] introducing RPC to an asynchronous protocol

john_patterson@us.ibm.com Wed, 29 August 2007 22:55 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 1IQWS5-0001zw-5n; Wed, 29 Aug 2007 18:55:57 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQWS1-0001th-QX for swmp@ietf.org; Wed, 29 Aug 2007 18:55:53 -0400
Received: from e34.co.us.ibm.com ([32.97.110.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQWRz-0007fV-2r for swmp@ietf.org; Wed, 29 Aug 2007 18:55:51 -0400
Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l7TMtna2001390 for <swmp@ietf.org>; Wed, 29 Aug 2007 18:55:49 -0400
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l7TMtndd352298 for <swmp@ietf.org>; Wed, 29 Aug 2007 16:55:49 -0600
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l7TMtm1i022368 for <swmp@ietf.org>; Wed, 29 Aug 2007 16:55:48 -0600
Received: from internet1.lotus.com (internet1.lotus.com [9.33.9.11]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7TMtklN022044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Aug 2007 16:55:47 -0600
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 l7TMtZg4025578; Wed, 29 Aug 2007 18:55:35 -0400 (EDT)
In-Reply-To: <20070824175624.CCC8446404E@william.mediamachines.com>
To: "Tony Parisi" <tparisi@mediamachines.com>
Subject: RE: [SWMP] introducing RPC to an asynchronous protocol
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0 August 18, 2005
Message-ID: <OF6D9A1A5C.CE491530-ON85257346.007DE1B0-85257346.007DE9D1@lotus.com>
From: john_patterson@us.ibm.com
Date: Wed, 29 Aug 2007 18:56:16 -0400
X-MIMETrack: Serialize by Router on WTFMAIL02/WTF/M/Lotus(Build V703_08192007|August 19, 2007) at 08/29/2007 06:56:18 PM, Serialize complete at 08/29/2007 06:56:18 PM
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
Cc: swmp@ietf.org
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="===============1764985646=="
Errors-To: swmp-bounces@ietf.org

Tony:

I do not see why it would need to be either/or.

The decision to do pub/sub is not really an option.  The paper described 
an implicit pub-sub.  I am advocating that we be explicit.

The more difficult question is whether a pub-sub approach is sufficient 
for all needs.  Given all the traffic that ensues when a subscription 
takes place, it seems unwise to SUBSCRIBE simply to learn a value and then 
turn around and UNSUBSCRIBE once it is known.  If we can identify 
situations in which it is important to learn the value of a field in order 
to decide whether to SUBSCRIBE, then I think we will want the GET 
functionality.

Imagine, for example, that we have a server that is managing multiple 
shards.  We are connecting our client, but we want to subscribe to the 
shard that is least occupied or that a friend is already in.  In these 
cases, we might want to query the shards for their load value and 
subscribe accordingly.  Or, query the shards to find our friend and then 
subscribe accordingly.  To subscribe to each shard simply to find these 
values would cause excess load on the server, the client, and the network. 
 It is worth avoiding.

jfp

"Tony Parisi" <tparisi@mediamachines.com> wrote on 08/24/2007 01:58:24 PM:

> If we?re talking about an either/or I prefer pub-sub to readback.
> 
> Tony
> 
> 
> From: Jay C. Weber [mailto:jweber@mediamachines.com] 
> Sent: Friday, August 24, 2007 9:04 AM
> To: john_patterson@us.ibm.com
> Cc: swmp@ietf.org
> Subject: [SWMP] introducing RPC to an asynchronous protocol
> 
> john_patterson@us.ibm.com wrote:

> D)  I believe that swmp will need the full complement of CRUD 
> (create, read, update, delete) operations.  I think the absence of 
> read methods derived from the implicit subscription to all state. 
> Now, that one can subscribe to some, but not all of the state, I 
> believe it will become desirable to request the values of 
> unsubscribed state.  This prompted me to add a GETNODE and a 
> GETFIELD request, which required GETNODEREPLY and GETFIELDREPLY 
> messages to return the response. 
> Interesting, but the danger here is "return the response".  There's 
> a big advantage to resisting the introduction of RPC-style elements 
> in a context of minimizing latency -- obviously RPC involves a 
> round-trip of messaging.  Keeping SWMP asynchronous will keep it 
> mapping simply and efficiently onto datagram transports.
> 
> I like the PUB-SUB suggestions you've made, especially because PUB-
> SUB can be designed to work well in an asynchronous protocol.
> 
> 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