[SWMP] Re: introducing RPC to an asynchronous protocol
john_patterson@us.ibm.com Fri, 24 August 2007 16:40 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 1IOcD8-0006Xi-9R; Fri, 24 Aug 2007 12:40:38 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOcD6-0006Xa-Hd for swmp@ietf.org; Fri, 24 Aug 2007 12:40:36 -0400
Received: from e3.ny.us.ibm.com ([32.97.182.143]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOcD5-0000xk-OW for swmp@ietf.org; Fri, 24 Aug 2007 12:40:36 -0400
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l7OGeZcO031218 for <swmp@ietf.org>; Fri, 24 Aug 2007 12:40:35 -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 l7OGeZuY430176 for <swmp@ietf.org>; Fri, 24 Aug 2007 12:40:35 -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 l7OGeZHi006450 for <swmp@ietf.org>; Fri, 24 Aug 2007 12:40:35 -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 l7OGeYnF006436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Aug 2007 12:40:35 -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 l7OGeYMb023681; Fri, 24 Aug 2007 12:40:34 -0400 (EDT)
In-Reply-To: <46CF0160.6020201@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: <OF431A5F6C.FD03E26E-ON85257341.005A22D8-85257341.005B94D3@lotus.com>
From: john_patterson@us.ibm.com
Date: Fri, 24 Aug 2007 12:41:12 -0400
X-MIMETrack: Serialize by Router on WTFMAIL02/WTF/M/Lotus(Build V703_08192007|August 19, 2007) at 08/24/2007 12:41:16 PM, Serialize complete at 08/24/2007 12:41:16 PM
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56
Cc: swmp@ietf.org
Subject: [SWMP] Re: introducing RPC to an asynchronous protocol
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="===============1531673547=="
Errors-To: swmp-bounces@ietf.org
Jay: I understand your concern about having request-response style messaging. I am worried that it cannot be completely avoided. Once we assume that there are multiple nodes to subscribe to, we face the possibility that it will be necessary to query the nodes to determine which one to subscribe to. Moreover, if you saw my discussion of a swmp url, we might find it desirable to query a node for some information (ie, the URL of its static representation) prior to actually subscribing. I do not feel that a query response capability in the protocol should be equated with an RPC mode of interaction. The problem in RPC is not that the protocol messages are synchronous; they're not. It is that the API for accessing the protocol is synchronous. A listener or callback approach can deal with this. I agree that a query facility might be problematic for a lossy transport so I would not recommend that it be used there. Frankly, the SUBSCRIBE message is even more problematic for UDP if the sequence of state updates that ensue are critical. My guess is that the decision of when to use TCP and when to use UDP for swmp will be a matter of some delicacy within an application. Personally, I would probably use TCP for most things and only use UDP for streams of updates where the loss of one update is no big deal (eg, position updates.) Indeed, one of the things I would like to do is subscribe on a TCP channel for updates that will occur on a UDP channel. I don't think we have anticipated that yet. jfp "Jay C. Weber" <jweber@mediamachines.com> 08/24/2007 12:03 PM To john_patterson@us.ibm.com cc swmp@ietf.org Subject 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
- Re: [SWMP] Re: faster field messages john_patterson
- [SWMP] My understanding so far john_patterson
- Re: [SWMP] My understanding so far Roland Weber
- Re: [SWMP] My understanding so far Jay C. Weber
- Re: [SWMP] My understanding so far john_patterson
- RE: [SWMP] My understanding so far Tony Parisi
- [SWMP] semantic layers Jay C. Weber
- [SWMP] field-creation semantics Jay C. Weber
- [SWMP] introducing RPC to an asynchronous protocol Jay C. Weber
- [SWMP] Re: semantic layers john_patterson
- [SWMP] faster field messages Jay C. Weber
- [SWMP] Re: field-creation semantics john_patterson
- [SWMP] Re: introducing RPC to an asynchronous pro… john_patterson
- RE: [SWMP] introducing RPC to an asynchronous pro… Tony Parisi
- RE: [SWMP] semantic layers Tony Parisi
- [SWMP] Re: faster field messages john_patterson
- [SWMP] Re: faster field messages Jay C. Weber
- [SWMP] Re: faster field messages john_patterson
- [SWMP] Re: faster field messages Jay C. Weber
- [SWMP] Re: faster field messages john_patterson
- RE: [SWMP] introducing RPC to an asynchronous pro… john_patterson
- RE: [SWMP] introducing RPC to an asynchronous pro… Tony Parisi
- Re: [SWMP] Re: faster field messages Roland Weber
- Re: [SWMP] My understanding so far Roland Weber
- Re: [SWMP] Re: faster field messages Roland Weber
- Re: [SWMP] My understanding so far john_patterson
- Re: [SWMP] My understanding so far Roland Weber
- Re: [SWMP] My understanding so far Jay C. Weber
- Re: [SWMP] My understanding so far Roland Weber