Good to see everyone having the HTTP spec discussion.This is the
preverbial elephant in the room for this network solution.
Regards
Teravus
On Tue, Oct 23, 2012 at 8:04 PM, Dahlia Trimble wrote:
> I believe the 2 persistent HTTP connections/server recommendation is just
> that: a maximum of
I believe the 2 persistent HTTP connections/server recommendation is just
that: a maximum of 2 *persistent* connections *per server*. Torrent
downloads are more likely 1 connection per server with many servers.
Torrent clients also have the ability for users to specify maximum outbound
transfer rat
On Tue, 23 Oct 2012 10:28:37 -0400, Monty Brandenberg wrote:
> Here's a chart I keep forwarding:
> http://www.smallnetbuilder.com/lanwan/router-charts/bar/77-max-simul-conn
> Not officially endorsed by Linden, etc., but a useful measure of
> one metric that is likely to predict problems. At the b
On Tue, 23 Oct 2012 11:05:38 -0700, Dahlia Trimble wrote:
> Would this excerpt from RFC2616 (section 8.2) be relevent? Perhaps some
> routers and other infrastructure assume this as design criteria:
>
> " Clients that use persistent connections SHOULD limit the number of
>simultaneous conne
On 2012-10-23 15:25 , Monty Brandenberg wrote:
On 10/23/2012 2:05 PM, Dahlia Trimble wrote:
Would this excerpt from RFC2616 (section 8.2) be relevent? Perhaps some
routers and other infrastructure assume this as design criteria:
Oh, it absolutely is but mostly honored in its breach. IETF 'SHO
On 10/23/2012 2:05 PM, Dahlia Trimble wrote:
> Would this excerpt from RFC2616 (section 8.2) be relevent? Perhaps some
> routers and other infrastructure assume this as design criteria:
Oh, it absolutely is but mostly honored in its breach. IETF 'SHOULD'
is so much weaker than its 'MUST'
_
On 2012-10-23 14:05 , Dahlia Trimble wrote:
> Would this excerpt from RFC2616 (section 8.2) be relevent? Perhaps
> some routers and other infrastructure assume this as design criteria:
> "
> Clients that use persistent connections SHOULD limit the number of
> simultaneous connections that
Would this excerpt from RFC2616 (section 8.2) be relevent? Perhaps some
routers and other infrastructure assume this as design criteria:
"
Clients that use persistent connections SHOULD limit the number of
simultaneous connections that they maintain to a given server. A
single-user clien
On 10/23/2012 6:10 AM, Henri Beauchamp wrote:
> And in fact, llappcorehttp.cpp only touches CP_CONNECTION_LIMIT, so
> CP_PER_HOST_CONNECTION_LIMIT is kept at its default (8) whatever the
> TextureFetchConcurrency debug setting value, meaning the viewer never
> opens more than 8 simultaneous connec
On 2012-10-23 06:10 , Henri Beauchamp wrote:
> Unless the router is buggy, it shouldn't be impacted by the number of
> open sockets (at least not under 60K sockets)... Some protocols, such
> as torrent can use hundreds or even thousands of sockets at once.
Our experience is that _many_ consumer ro
On Tue, 23 Oct 2012 00:01:29 -0400, Monty Brandenberg wrote:
> On 10/22/2012 6:28 PM, Henri Beauchamp wrote:
>
> > In the current implementation, the new HTTP core can be configured to
> > spawn from 12 to up to 256 (!) simultaneous connections... The texture
> > fetcher code however never queues
On 10/22/2012 6:28 PM, Henri Beauchamp wrote:
> In the current implementation, the new HTTP core can be configured to
> spawn from 12 to up to 256 (!) simultaneous connections... The texture
> fetcher code however never queues more than 40 requests at once, thus
> limiting the potential damages, b
On Mon, 22 Oct 2012 09:57:40 -0400, Oz Linden (Scott Lawrence) wrote:
> On 2012-10-20 11:14 , Henri Beauchamp wrote:
> > Is there any server running the corresponding improved HTTP code on
> > Aditi ?
>
> Not yet. When there is, we'll post a note on this list.
OK, thanks.
> As Tankmaster said,
On 2012-10-20 11:14 , Henri Beauchamp wrote:
> Is there any server running the corresponding improved HTTP code on
> Aditi ?
Not yet. When there is, we'll post a note on this list.
As Tankmaster said, our ambition at this point is that the server side
will be compatible with all existing viewer
The first faze is viewer changes only. Server side changes will be coming
later, but wont require viewer changes at this point. ~Tank > Date: Sat, 20 Oct
2012 17:14:04 +0200
> From: sl...@free.fr
> To: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] New
On Fri, 27 Jul 2012 13:46:22 -0400, Oz Linden (Scott Lawrence) wrote:
> The start of a unified approach to HTTP-based communications
> between the viewer and grid services with a goal of achieving
> reliability, consistency and a better overall experience on
> the grid.
>
> Pr
On Sat, 4 Aug 2012 00:52:40 +0200
Carlo Wood wrote:
> On Thu, 02 Aug 2012 12:21:20 -0700
> Kadah wrote:
>
> I stand corrected :/. And I'm disappointed in the mail viewer
> that I use (Claws Mail). I see nothing, and it treats your
> message as an attachment. When I click on that it allows
> me
On 2012-08-02 12:47 , Dahlia Trimble wrote:
>
> So, if pipelining is implemented and it works, what other bottlenecks
> are there that make multiple connections work so well?
>
Pipelining is not, unfortunately, supported yet on the servers... we're
working on that. And despite Carlos assertions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Using debian, I installed claws-mail-pgpinline plugin,
and can now see your mails as I should :). Thanks for
your kind patience!
- --
Carlo Wood
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQCVAwUBUBxY4m/Sxh1iSsrVAQI+lQP/XSbTU8
On Thu, 02 Aug 2012 12:21:20 -0700
Kadah wrote:
I stand corrected :/. And I'm disappointed in the mail viewer
that I use (Claws Mail). I see nothing, and it treats your
message as an attachment. When I click on that it allows
me to "Open" it with abiword -- which I normally only need
to open .doc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Oldest and nearest are different classes of things, but given the
context, I'm going to guess you meant far to near.
The texture priority is determined within the viewer, and, in theory
(and my understanding of code last time I worked around it), give
One side bar to this is the problem of what order textures are being fetched
Is the order still by oldest texture first or has that been fixed to
nearest texture first??
( it would help the expedience if the avatars textures were loaded
first and then the stuff near to the avatar was loaded [follow
Don't worry Carlo, I know better than to try to tell an engineer how to do
her/his job ;)
So, if pipelining is implemented and it works, what other bottlenecks are
there that make multiple connections work so well?
On Thu, Aug 2, 2012 at 10:14 AM, Carlo Wood wrote:
> On Thu, 2 Aug 2012 02:01:4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/2/2012 9:57 AM, Carlo Wood wrote:> Kadah,
> Please note that I cannot read your posts. They have no clear text
> in them, and exist only of a Microsoft(tm) company specific
> attachment.
>
> You might want to fix this.
I haven't used a MS emai
On Thu, 2 Aug 2012 02:01:45 -0700
Dahlia Trimble wrote:
> I can't help but think something is wrong here. A single TCP/IP link
> is more than capable of saturating available network bandwidth with
> efficient transfers of large volumes of data provided the end-points
> can produce and consume qu
: Thu, 02 Aug 2012 10:57 AM
Subject: Re: [opensource-dev] New HTTP Library & Project Viewer
On Tue, 31 Jul 2012 19:03:09 -0700
Kadah wrote:
Kadah,
Please note that I cannot read your posts. They have no clear text
in them, and exist only of a Microsoft(tm) company specific attachment.
You migh
On Tue, 31 Jul 2012 19:03:09 -0700
Kadah wrote:
Kadah,
Please note that I cannot read your posts. They have no clear text
in them, and exist only of a Microsoft(tm) company specific attachment.
You might want to fix this.
--
Carlo Wood
___
Policies
Wow. In excess of fourteen megabits per second of texture loading
madness with greatly reduced rendering stalls. Didn't take long to fill
up and hit discard bias of 5.0. Yes, we see some brief render stalls
after that, but from a different cause, I think.
_
I can't help but think something is wrong here. A single TCP/IP link is
more than capable of saturating available network bandwidth with efficient
transfers of large volumes of data provided the end-points can produce and
consume quickly enough.
It seems part of the problem may in the request/res
On 7/31/2012 10:03 PM, Kadah wrote:
> Its 8 again with the fallow comment. I tired to track down the rev,
> but apparently Mecurial 2.2 can't properly annotate that file for some
> reason, and the new UI for it in TortoiseHg2 is horrid. All of the
> referenced jiras around its changes are not publ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/30/2012 4:13 PM, Henri Beauchamp wrote:
> Don't put word in my mouths, that I never pronounced... I was not
> speaking about *persistent* connections. The current HTTP fetches
> are not persistent connections, and that's why 32 simultaneous
> requ
On 31/07/2012 9:13 AM, Henri Beauchamp wrote:
> On Mon, 30 Jul 2012 13:08:18 -0400, Oz Linden (Scott Lawrence) wrote:
>
>> HTTP itself recommends that clients not maintain more than 2 connections
>> to the same service [1]. I don't know exactly what limit we will decide
>> is reasonable (I expe
On Mon, 30 Jul 2012 13:08:18 -0400, Oz Linden (Scott Lawrence) wrote:
> On 2012-07-29 04:07 , Henri Beauchamp wrote:
> > With just a few tweakings to the texture fetcher (and in particular
> > a setting that permits up to 32 concurrent HTTP fetches),
>
> Caution... once we begin supporting persis
On Mon, Jul 30, 2012 at 3:04 PM, Monty Brandenberg wrote:
> On 7/30/2012 5:03 PM, Tateru Nino wrote:
>>
>> Heck, I know one person with two. A
>> Belkin G *and* a Linksys WRT.
>
> There's someone who I would like to buy a drink.
Im using my old wrt54gs with dd-wrt as a wireless access point/wired
On 7/30/2012 5:03 PM, Tateru Nino wrote:
>
> Heck, I know one person with two. A
> Belkin G *and* a Linksys WRT.
There's someone who I would like to buy a drink.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/
On 31/07/2012 3:20 AM, Oz Linden (Scott Lawrence) wrote:
> On 2012-07-29 13:58 , Sheet Spotter wrote:
>> Does increasing the HTTP connection limit also increase the burden on the
>> server and network?
>>
>> Increasing the HTTP connection limit on one client might improve the
>> experience for one
On 31/07/2012 5:28 AM, Monty Brandenberg wrote:
> On 7/30/2012 2:15 PM, Celierra Darling wrote:
>
>> FYI, the Firefox folks had a conversation in 2008 and decided to bump up
>> from 2 to 6 by default at that time (partly because everyone else was
>> raising it).[1] (And for what it's worth, I fou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/30/2012 10:20 AM, Oz Linden (Scott Lawrence) wrote:
> Opening many connections also puts additional strain on routers in
> the path that are doing connection tracking (which too many do),
> adding another possible source of problems.
It's a known
That's two connections at the process level, so that is not the limit for
each machine. For example, in hardware, each server machine may have eight
network cards on PC motherboards (by what was on the market), so each card
can have 12 connections for each server process, and each client process
h
On 7/30/2012 2:15 PM, Celierra Darling wrote:
> FYI, the Firefox folks had a conversation in 2008 and decided to bump up
> from 2 to 6 by default at that time (partly because everyone else was
> raising it).[1] (And for what it's worth, I found a mention from '06
> that "anything above 10 is exce
On Mon, Jul 30, 2012 at 1:08 PM, Oz Linden (Scott Lawrence)
wrote:
>
> On 2012-07-29 04:07 , Henri Beauchamp wrote:
>
> With just a few tweakings to the texture fetcher (and in particular
> a setting that permits up to 32 concurrent HTTP fetches),
>
>
> Caution... once we begin supporting persiste
On 2012-07-29 13:58 , Sheet Spotter wrote:
> Does increasing the HTTP connection limit also increase the burden on the
> server and network?
>
> Increasing the HTTP connection limit on one client might improve the
> experience for one person. It might also diminish the experience for
> everyone els
On 2012-07-29 04:07 , Henri Beauchamp wrote:
With just a few tweakings to the texture fetcher (and in particular
a setting that permits up to 32 concurrent HTTP fetches),
Caution... once we begin supporting persistent connections and pipelined
requests on the server side (we're working on it),
-Original Message-
From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Henri
Beauchamp
Sent: July 29, 2012 9:23 AM
To: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] New HTTP Library & Project Viewer
[...]
FYI, e
I would agree with you if all decent HTTP servers (Apache, but not
only), didn't have their own throttling algorithms are weren't able
to just drop the excess of connections when they run out of sockets.
But they do have such throttling mechanisms, so it's no issue at all
and in fact, 32 is the max
On Sun, 29 Jul 2012 10:07:18 +0200
Henri Beauchamp wrote:
> On Sun, 29 Jul 2012 05:23:15 +0200, Carlo Wood wrote:
>
> > On Fri, 27 Jul 2012 16:59:18 -0400
> > holydoughnuts wrote:
> >
> > The implementation that I wrote for Singularity (not yet in the
> > the official release) is more on the s
On Sun, 29 Jul 2012 05:23:15 +0200, Carlo Wood wrote:
> On Fri, 27 Jul 2012 16:59:18 -0400
> holydoughnuts wrote:
>
> The implementation that I wrote for Singularity (not yet in the
> the official release) is more on the side of "blazing fast" :p.
> The bottleneck is entirely server-side, but I'
On Fri, 27 Jul 2012 16:59:18 -0400
holydoughnuts wrote:
> On 7/27/2012 1:46 PM, Oz Linden (Scott Lawrence) wrote:
> > Project Viewer for testing is here:
> >
> > http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers#HTTP
> >
> > Especially if you have had problems when you enable
On 7/27/2012 1:46 PM, Oz Linden (Scott Lawrence) wrote:
> Project Viewer for testing is here:
>
> http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers#HTTP
>
> Especially if you have had problems when you enable the use of HTTP, we
> would very much appreciate your giving this a tr
The start of a unified approach to HTTP-based communications
between the viewer and grid services with a goal of achieving
reliability, consistency and a better overall experience on
the grid.
Project Viewer for testing is here:
http://wiki.secondlife.com/wiki/Linden_Lab_Offi
50 matches
Mail list logo
