[sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2

Dzonatas dzonatas at dzonux.net
Sat Jul 7 07:12:09 PDT 2007


First, let me reply to a few questions in summary here:

* Image Quality
On a questions about image quality comparisons, this is highly 
noticeable with sculpties that have the slightest artifact of 
difference. Higher quality images are not just about visible textures 
that go on the face a prim.

* Static Transfer Rates, Bandwdith, and Lag
On top of that is the cost, I believe people understand the cost of per 
GB that remote storage and colocation facilities charge. Besides that, 
there is also the immense bandwidth increase with larger images, so we 
also want to reduce the cost of server lag. For these reasons, the sim 
network can only be seen as a fallback rather than a primary resource to 
acquire the images.

* Squid &. P2P torrents
I did forget to jot down about Squid, but I did remember to put the 
"web" in between "p2p WEB textures." To make it clearer, I change the 
title of this to "P2P/Squid Web Textures."
Squid is not a drop-in solution from what has been found/tested so far. 
It works well in some situations and horrible in others. I'm thinking a 
shallow Squid that is P2P enabled to connect to others like Squids will 
be the best solution. The Squid would be able to determine if a P2P 
connection or a http redirect (to another Squid) is the best optimal 
route. It would be a custom solution, so there is no way to immediately 
use Squid as-is. It can help avoid sim and viewer changes, however.  
Main advantage here is the ability/potential to transfer smaller images 
faster without the bottleneck of torrent initialization. Main 
disadvantage: facilities like Amazon S3 only support P2P and can't do a 
custom squid.

* P2P Viewer-Side & Security
Obvious, the P2P option on the viewer side has to be optional. To enable 
P2P in the viewer is probably the easier solution, but not everyone will 
be able to use it. For those that can't use P2P in the viewer, they 
would have to override all request to the Squid texture server address. 
As for IP addresses, we could enable Tor, but I doubt it is really 
needed just to enable higher quality images.

* Aggregation/Combined Textures
Yep. This has been thought about in many ways. The sim server could 
currently patch tiles of images together and send them as one, but from 
what I gather this kind of option just won't happen on the sim level. It 
doesn't appear to be about process time, as it appears more about lag 
and that the sim network shouldn't be dealing directly with textures 
like they are now. The feature to combine textures together is a gain 
for optimal performance, especially over P2P. It is of lower-priority, 
however.

* P2P Scrapes/DHT
If there was a way to filter out non-SL users from scrapes and the DHT, 
this would help optimize torrents that are smaller in size. It's an 
idea, but I'd mark it down as lower-priority.

+++

There has already been some work done (or has been available) on the sim 
side. For the proof-of-concept stage, we don't need to make any sim side 
changes. In the future, special accounts can help the sim optimize the 
connection for daemons or provide an optional level of security.

A quick update to the steps without sim changes:

In order to improve the quality of textures without an increase in cost 
on the sims, we need to use P2P Web textures.

Steps required*:

1. A mod in the viewer that enables lossless compression for image uploads.
2. Optional use of the extra prim parameter 
(https://jira.secondlife.com/browse/SVC-350), to help redirect the 
viewer to Squid addresses or torrent trackers rather than the defaults.
3. A mod in the viewer to support P2P torrents -- made optional -- and 
default to Squid addresses.
4. An external site to host the default torrents, and a fallback to 
collect data from the sim for images that are not stored on the host 
Squid or found over DHT (if enabled).
5. A mod in a viewer to try to download all textures via the P2P/Squid 
method *first* from #4

*NOTE: These are just basic steps involved subject to change.

The other steps posted in the previous version help insure there won't 
be an extra cost hit on the sim network, so these were taken out to 
narrow the above list.

What else needs to change before we fill-in the details?

-- 
Power to Change the Void
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070707/548737d2/attachment.htm


More information about the SLDev mailing list