Swarming cache from your peer's computers

It's interesting, but one of the problems with the SL business model for me has always been BW consumption.

But think about it - what if instead of getting assets from their proxy server, you were simply handed a bunch of UUIDs and hashes and then you swarmed all over your peers computers for this information.

Not only is it possible that your download speeds would be reduced, but also load on the SL infrastructure would be reduced as well.

This makes things suddenly much more viable..

Are you Jarod's alt? Shall I out you in public?

The patent reply goes something like yes this is a great idea and definitely the direction SL will take but foo foo foo permissions foo foo security foo foo harder than foo.

Storing assets in a distributed database makes sense. Encrypt them and store them in the cache of clients, and use the existing asset server as seed in a BitTorrent way.

Also, what if the land data (geography and parcelling) was stored in one big such distributed database too ? And the simulators would instead just manage script execution and physics processing for the region. Or not: instead of tying each server to a geographic location, have them tie to a few client connections instead, so that each resident connects through a personal simulator that "follows" around. There would be no limit to the number of people gathering in the same place, resources would be used as needed, more efficiently, yadda yadda yadda.

I think I've seen all this discussed time and time again already. It might even be in the works for SL v2

We already have texture cache on our computers.

How would this be any less secure?

I'm not talking p2p / decentralized here.

I'm merely talking about offloading bandwidth on the LL infrastructure, so they can save money on bandwidth cpu resources.

It just makes me realise how going free wasn't really that bad an idea after all. Suddenly all those free accounts can be becomes useful assets to SL..

Interesting !

Come contribute to SL, it's free ! Even if you don't build / texture / script / socialize / play *ingo for play money, you can still contribute some hardrive space and bandwidth

I'd like to mention that we even have 3D data of other people's objects in RAM, and their textures in vidcard's memory. And their sounds in digital format in RAM or in the soundcard's buffer, too Oh the tragedy. I'm gonna start up $P2P_application and go look for a pirated copy of Rickard Roentgen's latest hovercar

It's not uncommon for an online research project to require that you install a small server on your system that will interact with a large collective during off hours.

If that can bring down the price of private sims / land, I'll certainly host a permanent server at home. Or 12. I smell a poll brewing.

[edit]
And if I can have my own server at home this way, I'll put a server rack in a closet.

This is a neat idea every time it comes up. Here's something I always wondered.

How would you deal with leeching? If someone had a really crappy connection would they be just an equal cog in the loop? Imagine grabbing things from a peer with a really bad network connection? Would ISP's start to filter out the ports SL was using (to save thier own bandwidth)?

What kind of bandwidth do you have at home? How would it hold up under 40 AV's at your place?

Well it wouldn't be peer to peer.

Peer to peer isn't centralized, whereas this would be fully centralized.

So dealing with leaching would be pretty easy.

In other words...a bittorrent-style media distribution system?

Yeah, bittorrent like.. but again, not so much p2p, which is what bit torrent is.

The idea would be to keep it simple and secure and just offload bandwidth requirements from SL servers.

Is there any incentive to leech with SL ?

I think distributed database is a better term.

Plus, it'll give SL some experience in some of the issues involved in going p2p if they were ever interested. And there are a lot of issues..

While this is an interesting idea, it seems to me downloading texture from your peers will have a lot of quality of service issues. People on home networks crash, shut down their computer, etc. all the time. I don't know much about swarm downloads, but I think designing an algorithm that would work well for SL's specific case will be non-trivial.

You make a good point, though, that the sim itself need not necessarily be the one to serve the textures. I can see in the future LL moving texture data away from the "center" of the internet towards the edges, closer to the client (perhaps via a service like akamai rather than some p2p/swarm network).

Actually, it's more like, "Blah blah streaming. Blah blah BLAH real-time. Blah blah blah."

This is LL's problem to deal with, not ours. Having a profitable business model is entirely up to them.

Regardless, I don't think this would work well. Users have a very small cache so only someone in the same sim would be likely to have the same textures which also leads on to that you usually don't have many avs in the typical sim, with the usually slow upload rates they won't be supplying much bandwidth.

I must disagree with that. For example, think of the sudden increase in availability of all somewhat default textures (including ground textures). The asset server wouldn't have to send those anymore, in all practicality. In effect it would mutualize the cache. Suddendly the asset server only has to send the rare/new stuff.

Also, there's little real-time issues since an object that is modified on the database is issued a new distinct UUID. No collisions.

Unfortunately, it also impacts many of who participate in this economy as well. What benefits SL benefits me, and what hurts them, hurts me.

The nature of swarming means that even low bandwidth can be added together to create very high bandwidth.

eg: if I download 2000K chunks a,b,c,d,e for a total of 10 megabytes, each one in 10s, that means my bandwidth is 10 meg / 10 seconds.