Re: [vwrap] Technical basis for VW client in a web browser?
Joshua Bell <josh@lindenlab.com> Mon, 20 December 2010 20:42 UTC
Return-Path: <josh@lindenlab.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id AB14F3A68C3 for <vwrap@core3.amsl.com>;
Mon, 20 Dec 2010 12:42:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.676
X-Spam-Level:
X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=0.300,
BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qkj-r+gxtg1L for
<vwrap@core3.amsl.com>; Mon, 20 Dec 2010 12:42:38 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com
[209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 4A67A3A68C5 for
<vwrap@ietf.org>; Mon, 20 Dec 2010 12:42:38 -0800 (PST)
Received: by gyd12 with SMTP id 12so1481190gyd.31 for <vwrap@ietf.org>;
Mon, 20 Dec 2010 12:44:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.90.10.21 with SMTP id 21mr6020020agj.112.1292877871510;
Mon, 20 Dec 2010 12:44:31 -0800 (PST)
Received: by 10.90.23.9 with HTTP; Mon, 20 Dec 2010 12:44:31 -0800 (PST)
In-Reply-To: <AANLkTinH+Ym6oQyKRAfsRiQ_LFjWLUFxtYjGQ0WNaDxf@mail.gmail.com>
References: <AANLkTintjQdAS=EWfiRu3oWenB42LKsNzJPDJ+5ofBRO@mail.gmail.com>
<AANLkTinhWObg6Te2VtGYKXsxBG5=gVDS5szmjtLeOgnm@mail.gmail.com>
<AANLkTikYn-iA7osXT_oW8rL61GhK57pp7uJVmTSGVvj7@mail.gmail.com>
<AANLkTikFWUxQyT9aNFBk7-Fdb5bNdFT9Bj-dehqVP0WN@mail.gmail.com>
<6.2.5.6.2.20101219141829.0a381da8@resistor.net>
<AANLkTik-1m=4OOeQN=D3w2t-G-f6DNKwDOmhT5_bNkmb@mail.gmail.com>
<AANLkTinMstkDv5iq6usxbe1djK7GkPrOAjpKYANyMxcy@mail.gmail.com>
<AANLkTimHUOwSMCWxAOyMH1O6XwiebOfep2AfN898pETR@mail.gmail.com>
<AANLkTi=LZ9s-dMmOUz79RrKbHcgMS-OU452qr4MS1ex+@mail.gmail.com>
<AANLkTinhzO0=hyxUy++g21uB00tkKqtbMuCEMP00nkki@mail.gmail.com>
<AANLkTinH+Ym6oQyKRAfsRiQ_LFjWLUFxtYjGQ0WNaDxf@mail.gmail.com>
Date: Mon, 20 Dec 2010 12:44:31 -0800
Message-ID: <AANLkTik2O41ZR_qJe2Ya7bmMbsrqjxcONCVGvfYL27G7@mail.gmail.com>
From: Joshua Bell <josh@lindenlab.com>
To: vwrap@ietf.org
Content-Type: multipart/alternative; boundary=0016361e890a44f5340497dd964a
Subject: Re: [vwrap] Technical basis for VW client in a web browser?
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group
<vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>,
<mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>,
<mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Dec 2010 20:42:39 -0000
The presentation I tried to give at IETF-77 (but we ran out of time, slides here: http://tools.ietf.org/agenda/77/slides/vwrap-6.pdf) broke down the SL protocol into three big buckets: (1) Request/Response (2) Streaming, Reliable (3) Streaming, Unreliable In terms of the overall SL protocol, in terms of both bytes sent and message types, the overwhelming majority falls into category #1. This includes resource fetching (textures, sounds, etc) and control of the world (change appearance, add friend, buy item, etc). For these, HTTP makes perfect sense as a transport (over TLS where necessary). (As Dahlia mentions, as subsystems of SL are modified we tend towards replacing both the transport of these message types and the endpoints with non-simulator HTTP.) Reliable streams are necessary for text chat, presence and other server-initiated notifications (downstream) and chat and avatar control (upstream). Currently these are transmitted over UDP, but this is ideally suited for TCP-based transmission, possibly using higher level protocols like XMPP for some/all of the message types. Unreliable streams are used in the SL protocol for transmitting scene graph updates, and also video and audio streams. (These non-VW media streams are handled by libraries not authored by Linden and use standard protocols like RTSP, so we usually ignore them in these discussions.) The justification is that latency is more important than accuracy and history of object positions is unnecessary. That said, it's unknown if, on the modern Internet, UDP is actually required, or if TCP with appropriate intelligence about what to send would suffice to provide an acceptable experience. Some testing has been done (I can't recall by who, though; I can track this down if necessary) with tunneling an SL connection (UDP+TCP traffic) over a TCP proxy, and the result was functional. This would indicate that, for at least some quality of connection and some subsets of content, TCP is adequate. (Not a surprise.) Whether a higher level protocol like RTSP would be beneficial as a transport for scene graph updates is also an open question. To SM's question of whether UDP WebSockets would be of interest: at least academically, yes. Are they necessary for the general case of an SL-like VW client implemented using Web standards in the browser? Unknown. Are they the long pole? Also unknown. -- Josh
- [vwrap] Technical basis for VW client in a web br… Morgaine
- Re: [vwrap] Technical basis for VW client in a we… Dahlia Trimble
- Re: [vwrap] Technical basis for VW client in a we… Morgaine
- Re: [vwrap] Technical basis for VW client in a we… Joshua Bell
- Re: [vwrap] Technical basis for VW client in a we… Meadhbh Hamrick
- Re: [vwrap] Technical basis for VW client in a we… Peter Saint-Andre
- Re: [vwrap] Technical basis for VW client in a we… Morgaine
- Re: [vwrap] Technical basis for VW client in a we… JohnnyB Hammerer
- Re: [vwrap] Technical basis for VW client in a we… peter host
- Re: [vwrap] Technical basis for VW client in a we… Brian Hurley
- Re: [vwrap] Technical basis for VW client in a we… Morgaine
- Re: [vwrap] Technical basis for VW client in a we… Morgaine
- Re: [vwrap] Technical basis for VW client in a we… Cristina Videira Lopes
- Re: [vwrap] Technical basis for VW client in a we… peter host
- Re: [vwrap] Technical basis for VW client in a we… SM
- Re: [vwrap] Technical basis for VW client in a we… Meadhbh Hamrick
- Re: [vwrap] Technical basis for VW client in a we… Dahlia Trimble
- Re: [vwrap] Technical basis for VW client in a we… Hurliman, John
- Re: [vwrap] Technical basis for VW client in a we… Mic Bowman
- Re: [vwrap] Technical basis for VW client in a we… Morgaine
- Re: [vwrap] Technical basis for VW client in a we… Dahlia Trimble
- Re: [vwrap] Technical basis for VW client in a we… Dan Olivares
- Re: [vwrap] Technical basis for VW client in a we… Dahlia Trimble
- Re: [vwrap] Technical basis for VW client in a we… Dan Olivares
- Re: [vwrap] Technical basis for VW client in a we… Joshua Bell
- Re: [vwrap] Technical basis for VW client in a we… Dahlia Trimble
- Re: [vwrap] Technical basis for VW client in a we… Morgaine
- Re: [vwrap] Technical basis for VW client in a we… Dahlia Trimble
- Re: [vwrap] Technical basis for VW client in a we… Dzonatas Sol
- Re: [vwrap] Technical basis for VW client in a we… Dzonatas Sol