[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