RE: [SWMP] introducing RPC to an asynchronous protocol

"Tony Parisi" <tparisi@mediamachines.com> Thu, 30 August 2007 05:29 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 1IQcaa-0006UJ-Md; Thu, 30 Aug 2007 01:29:08 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQcaZ-0006UC-8E for swmp@ietf.org; Thu, 30 Aug 2007 01:29:07 -0400
Received: from mx5.roble.com ([206.40.34.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQcaY-0001iZ-Ez for swmp@ietf.org; Thu, 30 Aug 2007 01:29:06 -0400
X-Scanned-By: PostConf Email Solutions
Received: from NEO (adsl-67-113-133-74.dsl.sntc01.pacbell.net [67.113.133.74]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: tony) by mail.mediamachines.com (Postfix) with ESMTP id 03FBF36441D; Wed, 29 Aug 2007 22:28:52 -0700 (PDT)
From: "Tony Parisi" <tparisi@mediamachines.com>
To: <john_patterson@us.ibm.com>
Subject: RE: [SWMP] introducing RPC to an asynchronous protocol
Date: Wed, 29 Aug 2007 22:28:52 -0700
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <OF6D9A1A5C.CE491530-ON85257346.007DE1B0-85257346.007DE9D1@lotus.com>
thread-index: Acfqj81dqOPwoIopQ3O8TDDS12xiKAANtKOQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
Message-Id: <20070830052853.03FBF36441D@mail.mediamachines.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e
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="===============1979662961=="
Errors-To: swmp-bounces@ietf.org

John

 

Agreed

 

Tony

 

  _____  

From: john_patterson@us.ibm.com [mailto:john_patterson@us.ibm.com] 
Sent: Wednesday, August 29, 2007 3:56 PM
To: Tony Parisi
Cc: 'Jay C. Weber'; swmp@ietf.org
Subject: RE: [SWMP] introducing RPC to an asynchronous protocol

 


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