Regional Cache Torrent Networks...

With the ever increasing load on the database it is rather obvious to me that Linden Labs is going to have heavy trouble pushing all the data this game requires centrally from central server locations.

So after some thought, its sort of hit me that what Second Life REALLY needs to be able to ease the load on its central databases is regional cache torrents between clients.

This is relatively simple to implement. The servers are already there, and the databases are there to provide the data and textures to clients as they rez into regions. But once a region has people in it...all those people have the regional textures and geometry data in their caches already.

So if the servers were running a peer to peer network allowing peer to peer transfer of regional data from all clients in the region, you could effectively reduce overall resource overhead and shift your bandwidth from the main database to the clients in the region.

The server would always be there to push the data if there were no users in the region. A user in the region once they'd received all the data for the region would become a regional seed, uploading at a minor bit rate to the local torrent network that all new users would connect to on entry, this would not only reduce load on the database but also INCREASE the overall resource transmission bandwidth availible because not only would the databases be providing data but so would the clients in the local region.

There is a potential here to see a massive reduction in database load, and increase overall Second Life performance regionally. And I think it could very well be the answer to the problems Second Life is facing as it expands.

Also since the networks would simply be sharing encrypted cache files, this option is no more or less secure than the platform already is. And Bit-Torrent is, for all intents and purposes an open protocol, so integration into Second Life would be nearly costless and simply a matter of integration.

I think this idea should be considered, it could go a long way towards helping us with the problems that face the platform at this time.

I think you really are on something there...


the P2p idea should work... will need a lot of effort to realise it but the outcome would be great!


Hey Linden! give that girl a job

Woot! I didn't understand a word but it sounds smartz!

I like the idea, but could this be used by malicious people to hit everyone entering a region with something nasty?

No, since the server would be controlling the MD5 hash for each file on the network that would be more or less impossible without MD5 hash decryption, and the file list would be different for every region. Would be far too much trouble to even bother with.

Sounds like an awesome idea to me.....Even if I don't understand all the technical speak ....LOL

no!

they would have to encrypt the cache files first

those cache files are on your pc at the moment too

which means the system would still be as secure as it was



Edited: Suzanna gave the answer like a second before me...lol

The only grief I had with this is that in low-traffic areas it would be the same as trying to download a torrent with no seeders. Suzanna elaborated on the idea in that the torrents would run parallel to the normal database, making it so that servers with low traffic would get the download rates they get now (sub-par.) I suppose the only other problem is encryption. I'm sure you will be able to design something secure, but there will always be one or two people cracking it and changing things around. This could spawn a whole new copybot type of problem in that people can simply break into a file, change some values and allow people to take textures, among possibly other things. Change some values could also be a problem if the file with different values than the rest of the files that are supposed to be the same thing gets mixed in. It could corrupt the texture or what have you.

If it can be implemented well and care is taken to secure it from nere-do-wells, this idea would make me glad I just renewed my paid membership.

I have to say I agree with Suzanna on this maybe using the ID's to locate textures on a grid-wide peer to peer network would help as well, given that many textures see a lot of re-use between simulators and regions.

Further on the security issue - the MD5 digest hash is a one-way hash algorithm, it cannot be reversed to get the original document. There is another attack which uses rainbow tables to match a set of known elements against the hash, but that is really only applicable to breaking passwords and not the more complex document types.

A grid wide P2P network might be a good idea as well, I was thinking regional adaptation at first to see how it worked. Since that way the resources are local to the region and its a smaller operation with less potential for flaws.

But a grid wide P2P network that would pull hash ID's for textures and objects and have the clients that have them cached help the network carry the load would be a logical extension of the idea.

The main difficulty here is that since LL has decided to not describe the workings of its asset servers in detail, it is impossible to know if this would really solve the overload problems.

- Is there trouble because LL doesn't have enough bandwidth or capacity to send out assets? If yes, then a distributed system could help matters.

- Is there trouble because LL doesn't have a sufficiently powerful database to handle search and records update requests? If yes, then a distributed asset system will not help.


Though at this point I think the trouble is more in the database search/update system rather than in the asset handling part of it.

Scalar, that is not true completely, part of the process of rezzing involves looking at prim data to determine what textures to retrieve (if you're curious about this process, turn on your message console adn restart the client, you can see the requests being made) - those requests could be directed first to a decentralised P2P network, before falling back on the linden servers.

If you imagine a sim of 20 people, each wearing say 100 prims, and each prim having a unique texture, then when you join that sim, that is 2000 texture requests you have to make - that could be handled directly by the P2P network.

I know this is old, but a few points (I build trackers in my spare time).

You know that bittorrent uses SHA1 to hash each piece yes? With the torrent controlled by the central servers, there is no need to MD5 anything, as the client can already check the SHA1 to validate pieces.

A client would not have to check a p2p network and then the central servers, as the central servers can be added as peers on the torrents. This way there would always be at least one seed.

I don't know what hashing algorithm is currently used (if any), but constantly hashing while travelling around in game could be a killer for HDD performance.

Many people have problems with bittorrent these days, with ISPs clamping down on its usage. Even encrypted header protocols are being broken. A lot of people would therefore contribute nothing to the swarm, leaving those who can use bittorrent to provide a lot of the bandwidth.

If torrents are used, there would definately have to be some configurable settings for upload speed. Bittorrent has been known to choke the entire pipe, making ACK responses impossible and therefore killing download speed.

Current note on asset server behaviour; all simulators cache things already, they have a local cache of assets, so once an asset is requested the simulator has it, and sends out this copy to the clients. The result being that once an asset is requested once, the sim uses local copies from then on (though if the caches aren't big enough swapping will start to occur where it has to keep requesting assets that won't fit or get kicked out of the cache).
So for typical simulators I'm not sure this will reduce asset server load by much if at all.

However, internally this could work a treat, as several simulators may have the same assets, so when another simulator requests that asset, it could download from all of them instead of the asset server itself. But it will rely on the relative cost of creating the torrents and stuff.