Re: [vwrap] Technical basis for VW client in a web browser?

Meadhbh Hamrick <ohmeadhbh@gmail.com> Sun, 19 December 2010 23:24 UTC

Return-Path: <ohmeadhbh@gmail.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 54EAB3A6952 for <vwrap@core3.amsl.com>; Sun, 19 Dec 2010 15:24:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 v0lsdyuCoSd0 for <vwrap@core3.amsl.com>; Sun, 19 Dec 2010 15:24:55 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 5F4043A694F for <vwrap@ietf.org>; Sun, 19 Dec 2010 15:24:55 -0800 (PST)
Received: by vws7 with SMTP id 7so1097547vws.31 for <vwrap@ietf.org>; Sun, 19 Dec 2010 15:26:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:received :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=HB2aZWJGcRoxlESRDNsYbK7g+iriABgJTpL1VFtRl4A=; b=T7rOUcO2O+dEl3SjILSV1gzKckxxytVMAT/nrrWXjpssbV3ySjinkp+COFa3A3B6hs j0BakL5uM5bl+j707rzS3/OhKUCC/Vau4WFQAKBK5Xetv/IYStpnBeHWeNujJJAp44QY JhKtt7C14weYK0iy7DyZgIq0pAm3MILrx3gCk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qHU3jhX5lTjWqV5wIeyqRmykmWwoe2ZGwKnjbKVxmAIswqIxAZdH2KYFrlhhTS5gLE pVkhGIZY5RTvicgU2dR2278j1SPEqdLi/UvE1n4EyigFT+WvUk4WA/yCmpkC9T5XQSRW 5ZFalfC0jkwwhJ54ATDo4wJGc0y0+FwhQm9MM=
MIME-Version: 1.0
Received: by 10.220.179.68 with SMTP id bp4mr1074276vcb.87.1292801207355; Sun, 19 Dec 2010 15:26:47 -0800 (PST)
Received: by 10.220.99.21 with HTTP; Sun, 19 Dec 2010 15:26:47 -0800 (PST)
Received: by 10.220.99.21 with HTTP; Sun, 19 Dec 2010 15:26:47 -0800 (PST)
In-Reply-To: <AANLkTik-1m=4OOeQN=D3w2t-G-f6DNKwDOmhT5_bNkmb@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>
Date: Sun, 19 Dec 2010 15:26:47 -0800
Message-ID: <AANLkTinMstkDv5iq6usxbe1djK7GkPrOAjpKYANyMxcy@mail.gmail.com>
From: Meadhbh Hamrick <ohmeadhbh@gmail.com>
To: SM <sm@resistor.net>
Content-Type: multipart/alternative; boundary=90e6ba53aab8bad47d0497cbbc95
Cc: vwrap@ietf.org
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: Sun, 19 Dec 2010 23:24:56 -0000

do we really know that UDP is what we want, even for low latency? if you're
multiplexing messages over a websocket connection, it's highly likely it'll
be an existing connection (i.e.- it's likely one tcp/ip connection will
carry several multiplexed websockets messages.)

in my tests, UDP doesn't do much better than TCP if you're near the network
rate as it seems a lot of routers tend to dump UDP packets first.

most modern OSes now have api calls to let you disable TCP slow-start.

i guess what i'm saying is it might be a good idea to define messages in a
way so they're transport agnostic. that and I would wager that any latency
improvements from UDP are dwarfed by latency introduced by application layer
mechanisms to replace TCP's flow control & resend semantics.

just my $0.02.
On Dec 19, 2010 2:34 PM, "SM" <sm@resistor.net> wrote: