[SWMP] Re: faster field messages
john_patterson@us.ibm.com Wed, 29 August 2007 16:02 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 1IQPzy-0003HD-TV; Wed, 29 Aug 2007 12:02:30 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPzw-0003DS-QW for swmp@ietf.org; Wed, 29 Aug 2007 12:02:28 -0400
Received: from e5.ny.us.ibm.com ([32.97.182.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQPzv-00075o-V8 for swmp@ietf.org; Wed, 29 Aug 2007 12:02:28 -0400
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l7TG2QeH014323 for <swmp@ietf.org>; Wed, 29 Aug 2007 12:02:26 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l7TG2QRP546316 for <swmp@ietf.org>; Wed, 29 Aug 2007 12:02:26 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l7TG2QUO019875 for <swmp@ietf.org>; Wed, 29 Aug 2007 12:02:26 -0400
Received: from internet1.lotus.com (internet1.lotus.com [9.33.9.11]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7TG2P2n019846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Aug 2007 12:02:26 -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 l7TG2PwE022267; Wed, 29 Aug 2007 12:02:25 -0400 (EDT)
In-Reply-To: <46D58A41.4040508@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: <OF95516987.80B2064B-ON85257346.00579557-85257346.00581671@lotus.com>
From: john_patterson@us.ibm.com
Date: Wed, 29 Aug 2007 12:03:07 -0400
X-MIMETrack: Serialize by Router on WTFMAIL02/WTF/M/Lotus(Build V703_08192007|August 19, 2007) at 08/29/2007 12:03:08 PM, Serialize complete at 08/29/2007 12:03:08 PM
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48
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="===============0325199330=="
Errors-To: swmp-bounces@ietf.org
Jay: I think the thing I missed was the unidirectionality of the mapping. So each side gets to declare its own mapping and the other is obligated to keep track of that. Servers can use the same id for everyone becasue they get to declare the id they'll use. Can I declare a mapping on a reliable channel (TCP) and use it on an unreliable channel (UDP)? That would be helpful, since the first use establishing the mapping should be protected from loss. It seems a little complicated, but I am inclined to accept your arguments for the ease of implementation and the virtues of the approach in a peer-to-peer context. Thanks for explaining how it works. jfp "Jay C. Weber" <jweber@mediamachines.com> 08/29/2007 11:01 AM To john_patterson@us.ibm.com cc swmp@ietf.org Subject Re: faster field messages john_patterson@us.ibm.com wrote: 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>. Yes but as I defined it that mapping only applies in that one direction of the communication. E.g., element A tells element B that "I will use the id '2' to represent the pair <node12,positionfield>", which constrains the meaning of future messages from A, but does not say anything about what field ids B will use in messages to A. 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. The server in my current client/server architecture (and implementation) does already use the same ID mapping for messages to all its clients, possible because of this unidirectionality of field ids. This is indeed very convenient when blasting out an update to all the clients, not having to customize field ids for each message. (and this is really important for an architecture that uses multicast.) But you are right that my server maintains independent mappings for each inbound message queue. This requires some bookkeeping but is not complicated, and it is not any more space inefficient in the typical case where the clients are frequently changing distinct sets of nodes and their fields -- e.g., where each client controls his/her avatar and not others'. The main advantages of this fieldid-definition-unidirectionality are that it avoids architectural limitations (baking in a master-slave relationship of fieldid-definition wouldn't be appropriate, say, for a peer-to-peer architecture), race conditions (peers racing to be the first to define a fieldid), or a centralized fieldid-definition service (which involves race conditions and either architectural limitations or a potential bottleneck). jay
_______________________________________________ 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