Re: [SWMP] My understanding so far
Roland Weber <ossfwot@dubioso.net> Fri, 31 August 2007 17:05 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 1IR9vY-00027o-Ii; Fri, 31 Aug 2007 13:05:00 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR9vW-0001s0-Eu for swmp@ietf.org; Fri, 31 Aug 2007 13:04:58 -0400
Received: from moutng.kundenserver.de ([212.227.126.177]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IR9vV-00040F-RP for swmp@ietf.org; Fri, 31 Aug 2007 13:04:58 -0400
Received: from e180008012.adsl.alicedsl.de [85.180.8.12] (helo=[85.180.8.12]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1IR9vU3T8b-0002KV; Fri, 31 Aug 2007 19:04:57 +0200
Message-ID: <46D84A4C.6070007@dubioso.net>
Date: Fri, 31 Aug 2007 19:05:16 +0200
From: Roland Weber <ossfwot@dubioso.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070807 SeaMonkey/1.1.4
MIME-Version: 1.0
To: swmp@ietf.org
Subject: Re: [SWMP] My understanding so far
References: <OFE08B3427.B3EA5603-ON8525732C.0077710F-85257333.0024F03B@lotus.com> <46BC9717.4060103@dubioso.net>
In-Reply-To: <46BC9717.4060103@dubioso.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V01U2FsdGVkX18WW2eoD5ristNVSjtSRTYHWEofkomZ1yk0bCG /5xtY1g1Rs2nmZAP/+iLZ0WYlfuuK0qvN+eBQYjgXmEbjeGipn BPr+jZZVJPxSP0fyyuQ4RRoQAHcd/dO
X-Spam-Score: 1.7 (+)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
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>
Errors-To: swmp-bounces@ietf.org
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. 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. 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? 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. cheers, Roland [1] www.mediamachines.com/hydra/swampweb3d2007.pdf _______________________________________________ SWMP mailing list SWMP@ietf.org https://www1.ietf.org/mailman/listinfo/swmp
- Re: [SWMP] Re: faster field messages john_patterson
- [SWMP] My understanding so far john_patterson
- Re: [SWMP] My understanding so far Roland Weber
- Re: [SWMP] My understanding so far Jay C. Weber
- Re: [SWMP] My understanding so far john_patterson
- RE: [SWMP] My understanding so far Tony Parisi
- [SWMP] semantic layers Jay C. Weber
- [SWMP] field-creation semantics Jay C. Weber
- [SWMP] introducing RPC to an asynchronous protocol Jay C. Weber
- [SWMP] Re: semantic layers john_patterson
- [SWMP] faster field messages Jay C. Weber
- [SWMP] Re: field-creation semantics john_patterson
- [SWMP] Re: introducing RPC to an asynchronous pro… john_patterson
- RE: [SWMP] introducing RPC to an asynchronous pro… Tony Parisi
- RE: [SWMP] semantic layers Tony Parisi
- [SWMP] Re: faster field messages john_patterson
- [SWMP] Re: faster field messages Jay C. Weber
- [SWMP] Re: faster field messages john_patterson
- [SWMP] Re: faster field messages Jay C. Weber
- [SWMP] Re: faster field messages john_patterson
- RE: [SWMP] introducing RPC to an asynchronous pro… john_patterson
- RE: [SWMP] introducing RPC to an asynchronous pro… Tony Parisi
- Re: [SWMP] Re: faster field messages Roland Weber
- Re: [SWMP] My understanding so far Roland Weber
- Re: [SWMP] Re: faster field messages Roland Weber
- Re: [SWMP] My understanding so far john_patterson
- Re: [SWMP] My understanding so far Roland Weber
- Re: [SWMP] My understanding so far Jay C. Weber
- Re: [SWMP] My understanding so far Roland Weber