Re: [SWMP] Re: faster field messages Fri, 31 August 2007 19:36 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IRCI3-00052J-Ox; Fri, 31 Aug 2007 15:36:23 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IRCI2-00051r-3F for; Fri, 31 Aug 2007 15:36:22 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1IRCI1-00016V-9M for; Fri, 31 Aug 2007 15:36:21 -0400
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id l7VJaKoH013482 for <>; Fri, 31 Aug 2007 15:36:20 -0400
Received: from ( []) by (8.13.8/8.13.8/NCO v8.5) with ESMTP id l7VJaK28436170 for <>; Fri, 31 Aug 2007 15:36:20 -0400
Received: from (loopback []) by ( with ESMTP id l7VJaKle015865 for <>; Fri, 31 Aug 2007 15:36:20 -0400
Received: from ( []) by ( with ESMTP id l7VJaJl1015852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 31 Aug 2007 15:36:20 -0400
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id l7VJaJVO018667; Fri, 31 Aug 2007 15:36:19 -0400 (EDT)
In-Reply-To: <>
To: Roland Weber <>
Subject: Re: [SWMP] Re: faster field messages
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0 August 18, 2005
Message-ID: <>
Date: Fri, 31 Aug 2007 15:36:59 -0400
X-MIMETrack: Serialize by Router on WTFMAIL02/WTF/M/Lotus(Build V703_08192007|August 19, 2007) at 08/31/2007 03:37:03 PM, Serialize complete at 08/31/2007 03:37:03 PM
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of a Simple Wide-area Multiuser-3D Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0420418756=="


I assumed that the IDs are valid for a session, i.e., the messages between 
the HELLO and the BYE.

I also assume that any network element wishing to use an ID must first 
send a SET message establishing the mapping for that node, which can be 
followed by later SETF messages that use the ID.

I assume that at any time a SET message may be issued to change the ID 
that is being used even if there have been prior SETF messages using an 
earlier ID.

I assume that if a network element cannot formulate a legitimate ID that 
SET messages may be used in lieu of a SETF message.  This would mean that 
a pre-established limit would be acceptable, if large enough to cover most 

I believe it is an ad hoc mechanism, but I assumed it was to make the 
processing more efficient.  I'm not sure whether the focus was on 
networking issues or lookup efficiency on the network elements.  I assume 
the technique was introduced because the X3D data model has within-node 
names for fields. 


Roland Weber <> wrote on 08/31/2007 12:33:37 PM:

> > 
> > So each side gets to declare its own mapping and the other is 
obligated to 
> > keep track of that.
> What are the limits, like a maximum number of mappings, or a
> maximum guaranteed lifetime of mappings? Unlimited mappings
> that each peer needs to keep track of open the gate for easy
> DoS attacks. Negotiated limits with each peer would not allow
> a server to use the same mappings for each client.
> One approach would be that a peer advertises how many mappings
> it is going to use, so that the partner can decide on whether
> to accept that number or cancel the connection. Another is to
> define a maximum number in the protocol, like 255 or 256. That
> may be too restrictive, but allowing two bytes and more than
> 65000 mappings will trigger memory problems, in particular on
> a server.
> >From the paper (I've read it by now) I perceived it rather
> as an ad hoc technique used to shrink the size of a group of
> messages in an UDP packet. In that case, the lifetime of a
> mapping could be restricted to the packet. But that doesn't
> map to TCP connections, or your discussion of defining the
> mappings on a separate channel.
> In the extreme case of ad hoc, you'd have only one mapping
> which is defined at the beginning of a sequence of messages
> referring to the same node, and overwritten by the next
> definition. Actually, that's not even a mapping anymore,
> but an implicit argument.
> cheers,
>   Roland
> _______________________________________________
> SWMP mailing list
SWMP mailing list