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 <ca...@alinoe.com> wrote: > On Thu, 2 Aug 2012 02:01:45 -0700 > Dahlia Trimble <dahliatrim...@gmail.com> 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 quickly enough. > > > > It seems part of the problem may in the request/response nature of > > HTTP. The viewer needs to make a request for each asset it needs as > > it discovers it needs it. It sends a request for each asset, and the > > provider endpoint then has to do whatever it does to make the asset > > available before beginning to send it back to the client. This may > > occur relatively instantly in the case of assets in a server memory > > cache, or a lot longer depending on where it needs to be pulled from > > or how it may need to be prepared. Assuming this is the case, having > > multiple overlapping requests can improve the overall download rate > > of multiple assets by allowing some downloads to occur while others > > are prepared, albeit at the expense of additional connections. Having > > a persistent connection reduces some of the delays introduced by > > re-establishing a connection for each asset, but it does nothing to > > reduce the time that the server endpoint needs to acquire and prepare > > the asset to send. > > > > Now (assuming this isn't the case already) if the producer endpoint > > could be made aware of future requests, it could fetch and prepare > > the asset for transfer prior to the actual request being received, > > thereby reducing or eliminating the time delays inherent in the > > request-response paradigm. This *may* be as simple as adding > > additional optional UUIDs and parameters to the asset request for > > assets that the viewer would likely be requesting next. If this were > > the case, a single connection could have a higher effective > > throughput by ensuring minimal delays between request and response, > > and reduce the need for more simultaneous connections. > > > > Such a solution may or may not be practical or easily implemented in > > existing infrastructure, or may not be as efficient as other designs. > > My point is more or less meant to bring more perspectives into the > > discussion by considering other bottlenecks that may exist, which if > > mitigated, could reduce the need for excessive connections. > > > > Thoughts? > > -dahlia > > Dahlia, an overwhelming amount of past experience has taught us that > Linden Lab is not interested if you "think along" with them about the > server, or the viewer-server protocol,either with suggestions, designs > or anything. This list is set up to get feedback about viewer bugs, and > to announce things they came up with (in most cases someone else came up > with than the ones that we're allowed to talk with). So, it's a complete > waste of your time to do anything else than to just sit back and read > what Linden Lab is going to push through (no matter what arguments you > come with, or what flaws you point out). > > [ That being said, they came up with "pipelining" as the solution for > the problem you mention. That allows a viewer to send new requests over > the same connection, without having to wait for a reply for former > requests. This isn't the most efficient solution, but a lot better > (still depending on the closed source server implementation though) > than how it works so far. ] > > -- > Carlo Wood <ca...@alinoe.com> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
