[SWMP] Re: faster field messages

"Jay C. Weber" <jweber@mediamachines.com> Wed, 29 August 2007 15:01 UTC

Return-path: <swmp-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQP3B-0003nA-39; Wed, 29 Aug 2007 11:01:45 -0400
Received: from [] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQP3A-0003mz-CT for swmp@ietf.org; Wed, 29 Aug 2007 11:01:44 -0400
Received: from mx5.roble.com ([]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQP39-00049E-Qu for swmp@ietf.org; Wed, 29 Aug 2007 11:01:44 -0400
X-Scanned-By: PostConf Email Solutions
Received: from [] (h-66-134-93-202.snvacaid.covad.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jay) by mail.mediamachines.com (Postfix) with ESMTP id 6C260364440; Wed, 29 Aug 2007 08:01:16 -0700 (PDT)
Message-ID: <46D58A41.4040508@mediamachines.com>
Date: Wed, 29 Aug 2007 08:01:21 -0700
From: "Jay C. Weber" <jweber@mediamachines.com>
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: john_patterson@us.ibm.com
References: <OFEC8B3B5C.325A7433-ON85257346.00470B2F-85257346.004AC0D4@lotus.com>
In-Reply-To: <OFEC8B3B5C.325A7433-ON85257346.00470B2F-85257346.004AC0D4@lotus.com>
X-Spam-Score: 1.7 (+)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
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="===============0019153082=="
Errors-To: swmp-bounces@ietf.org

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).


SWMP mailing list