Re: [SWMP] My understanding so far Fri, 31 August 2007 20:32 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IRDAi-0005Pp-2T; Fri, 31 Aug 2007 16:32:52 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IRDAh-0005Me-20 for; Fri, 31 Aug 2007 16:32:51 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1IRDAf-0002DV-DN for; Fri, 31 Aug 2007 16:32:51 -0400
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id l7VKWcRe027015 for <>; Fri, 31 Aug 2007 16:32:38 -0400
Received: from ( []) by (8.13.8/8.13.8/NCO v8.5) with ESMTP id l7VKWc3h497592 for <>; Fri, 31 Aug 2007 14:32:38 -0600
Received: from (loopback []) by ( with ESMTP id l7VKWcI9016247 for <>; Fri, 31 Aug 2007 14:32:38 -0600
Received: from ( []) by ( with ESMTP id l7VKWbbU016195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 31 Aug 2007 14:32:38 -0600
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id l7VKWbuO022900; Fri, 31 Aug 2007 16:32:37 -0400 (EDT)
In-Reply-To: <>
To: Roland Weber <>
Subject: Re: [SWMP] My understanding so far
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0 August 18, 2005
Message-ID: <>
Date: Fri, 31 Aug 2007 16:33:17 -0400
X-MIMETrack: Serialize by Router on WTFMAIL02/WTF/M/Lotus(Build V703_08192007|August 19, 2007) at 08/31/2007 04:33:20 PM, Serialize complete at 08/31/2007 04:33:20 PM
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0
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="===============2135977442=="


My responses are mixed in.


Roland Weber <> wrote on 08/31/2007 01:05:16 PM:

> Hi all,
> I've read the paper[1] by now, and it answered some of
> my questions while raising new ones.
> A question that is answered is about tickets. They are
> representing peers rather than connection, so a ticket
> is sent once over the initial channel, then received
> later over all side channels too. Sending an unmodifiable
> ticket as an authentication token with every UDP packet
> sounds somehow like HTTP basic auth. Once somebody has
> intercepted the ticket, that entity can generate new
> messages that will look genuine. Some hashing technique
> including a secret value that is exchanged only once in
> advance could improve on both security and message size,
> but it's probably too early to discuss security now.

I did not understand that about tickets.  The security concern seems 
legitimate.  The solution sounds sensible, especially because it will 
apply to all channels.  I agree that it might be too early to worry deeply 
about security, but it can't hurt to have it in mind.

> The paper mentions limited support for multicast, but
> does not elaborate. There's some more background reading
> I'll have to do, but for now I imagine that a multicast
> channel is unidirectional, and typically from a server
> to many clients. There are two problems with that:
> - no HELLO message exchange, because a client can't
>   send back (over that side channel)
> - no client-specific ticket in the messages sent
> I understand that multicast has a low priority here, but
> maybe it is still useful to give it a thought occasionally.

I share the impression that multicast was a bit of an afterthought in the 
paper.  Nevertheless, the sentiment to support it is a good one.  It 
sounds like we need to think more deeply about how that might happen.

> Then there are the message IDs. In the paper, they are
> per channel and used for UDP packets only. All messages
> in a packet share the same message ID. In John's summary,
> message IDs are suggested for two purposes:
>   a) to identify requests in FAILNOTIFY
>   b) as a replacement for timestamps in SUBSCRIBE
> The former has the problem that a message ID as presented
> in the paper is not unique for a request, and requests via
> TCP will not even have a message ID. There is a huge gap
> between the interpretations in the paper and the summary.
> Did I miss some discussion on that?

No, you didn't miss any discussion on that.  My adoption of the message 
IDs to solve some of the problems I was encountering was rather "glib".  I 
did not understand that message IDs were per packet and not per message. I 
also did not understand that they were only used with UDP.  The paper did 
not anticipate using message IDs in this way because it does not support 
queries, failure notifications, or subscriptions with an indication of the 
relative completeness of the current state.  As I have mentioned 
elsewhere, I no longer believe that message IDs are a good idea for 
subscriptions.  I still think that failure notifications and queries will 
be needed.

> The latter has the problem that it is impossible to map
> message IDs to unique points in (virtual) time because
> they are per-channel, non-persistent, and not unique even
> on a single channel. In order to implement a mechanism like
> "send all changes since my last login from this machine",
> a server will need some kind of timestamp, probably based
> on a virtual time in the model.

I agree with your point about using message IDs on subscriptions.  We 
could just say that all subscriptions are followed by a full accounting of 
the state.  Or, if we want to manage the traffic better, we will need some 
notion of time to account for how far back the subscriber's state is 
valid.  If we can figure out how to use time in this fashion, it might 
decrease the traffic a lot.

> cheers,
>   Roland
> [1]
> _______________________________________________
> SWMP mailing list
SWMP mailing list