[SWMP] Re: semantic layers

john_patterson@us.ibm.com Fri, 24 August 2007 16:12 UTC

Return-path: <swmp-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOblV-0003xB-Lr; Fri, 24 Aug 2007 12:12:05 -0400
Received: from [] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOblU-0003p9-Eu for swmp@ietf.org; Fri, 24 Aug 2007 12:12:04 -0400
Received: from e31.co.us.ibm.com ([]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOblT-00086A-9E for swmp@ietf.org; Fri, 24 Aug 2007 12:12:04 -0400
Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com []) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l7OGBoPa027579 for <swmp@ietf.org>; Fri, 24 Aug 2007 12:11:50 -0400
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com []) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l7OGBolK173872 for <swmp@ietf.org>; Fri, 24 Aug 2007 10:11:50 -0600
Received: from d03av03.boulder.ibm.com (loopback []) by d03av03.boulder.ibm.com ( with ESMTP id l7OGBo7R015190 for <swmp@ietf.org>; Fri, 24 Aug 2007 10:11:50 -0600
Received: from internet1.lotus.com (internet1.lotus.com []) by d03av03.boulder.ibm.com ( with ESMTP id l7OGBnYo015092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Aug 2007 10:11:49 -0600
Received: from wtfmail02.edc.lotus.com (wtfmail02.lotus.com []) by internet1.lotus.com (8.14.1/8.14.1) with ESMTP id l7OGBmPh021715; Fri, 24 Aug 2007 12:11:48 -0400 (EDT)
In-Reply-To: <46CEFBA9.60602@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: <OF3E85494A.DA56C0EB-ON85257341.005793A1-85257341.0058F2E4@lotus.com>
From: john_patterson@us.ibm.com
Date: Fri, 24 Aug 2007 12:12:26 -0400
X-MIMETrack: Serialize by Router on WTFMAIL02/WTF/M/Lotus(Build V703_08192007|August 19, 2007) at 08/24/2007 12:12:31 PM, Serialize complete at 08/24/2007 12:12:31 PM
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e
Cc: swmp@ietf.org
Subject: [SWMP] Re: semantic layers
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="===============1143692623=="
Errors-To: swmp-bounces@ietf.org


I understand that in a client-server setup the role would disambiguate the 
message, but I don't see what is gained by making the message be the same. 
 There is no real saving in the protocol by using the same name for 
different purposes and it can be confusing to anyone trying to understand 
the protocol.  I lean in the direction of avoiding overloading messages. 
For distinct purposes, I am inclined to use distinct messages.  I don't 
think the code cares either way and it makes the whole thing clearer to 
anyone studying the protocol.

As for peer-to-peer situations, I was worried whether there might be 
situations in which the ambiguity of SET might create difficulties.  I 
haven't really figured it all out, but the kind of thing I was worried 
about was cycles in which a peer is receiving a SET message as 
notification for a change that it actually originated.  Being unable to 
tell that it is a notification and not a request for change, it might 
apply the change and send out its notifications and simply keep the cycle 
going.  My guess is that a simple two peer setup could detect and suppress 
the problem.  Perhaps it is only an issue when there are three or more 
peers and the communication patterns form a cycle.

In any case, I think it is better to use separate messages for distinct 
purposes.  The protocol only looks simpler in its message count.  For the 
diligent student of the protocol, overloading can actually make it all 
more complex.


"Jay C. Weber" <jweber@mediamachines.com> 
08/24/2007 11:39 AM

semantic layers

Jon: there are many issues in your note so I will respond in pieces, so we 
can discuss issues separately and without undue reading burden on the 
others :-)

john_patterson@us.ibm.com wrote: 
A)  As originally specified, swmp does not distinguish between requesting 
a state change and being notified of a state change.  It tends to treat 
the state sharing as largely a replication task with neither network 
element having a controlling role over the state.  I think it is more 
realistic and practical to assume that each network element has control 
over its state and the other network element may request changes and be 
notified when changes happen.
I agree that distinction is important.  The original SWMP doesn't take a 
position on which elements have a controlling role, leaving that to the 
semantics of the architecture.  My intent was to separate the two layers 
of semantics, so that the protocol would be kept simple and be applicable 
to many different architectures.

E.g., a peer-peer architecture would specify, as you say, that "each 
network element has control over its state and the other network element 
may request changes and be notified when changes happen", but some 
client-server architectures (including most MMOGs) vest all control over 
state in the server element.  That is, a state message from the server is 
always an authoritative notification, and a state message from a client is 
always a provisional request.  In such an architecture, network elements 
get this semantics from their known roles, they don't need to get it from 
inside the messages.

Jay C. Weber, Ph.D. 
CTO, Media Machines Inc. 
SWMP mailing list