Major Bandwidth Savings with P2P

Very new to the world, but what is instantly recognizable is the way objects are downloaded to the client when needed. Exactly like AlphaWorld back in the day. I'm sure the bandwidth usage by your data server is very large. With multiple people in the same zone it is likely one person already has the downloadable content another person needs.

Instead of the client downloading directly from the server, the server tells the client the hash and size of the file with a list of client addresses that already have it. The client can then download the file from a random alternate client. The hash is used to verify the file's integrity, preventing hacks. I suggest MD5, its fast.

You could even put in a setting that lets a user keep SL open in the tray even when they're not in SL for the purpose of helping distribute content. Your company's bandwidth savings in exchange for a few linden dollars of course. Now there's an idea

there is another thread with this idea already stated i think in one of the other support forums.

The problem boils down to three things:

1) Clients aren't trustworthy
2) Upload speeds aren't high enough
3) There's no need for it.

It occurs to me that the place where this WOULD be practical --or at least, less impractical-- would be on LANs. Suppose I and my (hypothetical) partner both enjoy SL, and use it frequently, thanks to our non-Linksys router. Now, assuming we do the exact same things, our combined bandwidth usage is going to be twice as much as it would otherwise. This is completely unnecessary. Most of that data is textures and sounds, all data that we only REALLY need to download once.

I suggest that we FIRST be able to relocate the cache from its hardcoded location, then allow us to connect to a proxy server on the LAN. Content could be requested by the client and stored on both the client and the LAN cache. It could be used as a sort of mini dataserver, scalable and able to be updated as the clients requested data. THAT would provide some real bandwidth savings.

The question, as always, is whether or not the time and effort spent attempting to implement this is worth the payoff. In this case, probably not. Still, it's something to consider.

First let me respond to Carnildo


Thats why the server gives the client the hash and size of the file so that the client can self-verify it is the correct file. Hash and size data total is 20 bytes, most files are more than 2,000 bytes.


Flying around SL my average download speed from the server is 300 kbs. The max download speed for a common cable modem is 1,440 kbs. Downloading the files needed simultaneously from multiple clients could reach that speed bringing a 5x reduction in wait time and almost instant gratification to the user. A common cable modem's upload speed is 240 kbs, compared with the downspeed from the SL server of 300 kbs, and then imaging downloading from multiple clients simultaneously, it only takes 6 connections to other peers to max out your download speed.


SL is about the advancement of metaverse technology. In the building and scripting department they're ahead. But in the streaming content department they are still where AlphaWorld was 7 years ago, flying around SL gives you the same feeling as flying around AlphaWorld with the slow object popups and load times.

Catherine I'm not sure what you're saying, each peer connected to SL is its own cache that can be used to stream content. Currently when in SL your upload bandwidth is nill and could be used to speed everyone's load times including yours. It should be an optional feature to share back to the network, and turned on you should be rewarded with a few linden dollars for it.

Now some more technical stuff (I've been coding P2P systems for 4 years)
This is not complicated like most P2P systems out there, the central SL server dictates what files the client needs and the alterate client addresses those files can be obtained from. Files are usually in the KB range so there's no need for multi-source downloading of the same file like BitTorrent or sub-part tigertree hashing. This simplifies things even more. The protocol is simple, request, receive, can be HTTP or done with fixed binary to save bandwidth. With a 'push' mechanism even users behind firewalls can contribute.

By decreasing load on the servers and improving user experience, its not only a smart technology descision its a smart business decision.

Let's say I hack my client to upload random data to anyone that connects. This amounts to a DoS attack on them and an unknown third party, as their client then needs to download the data twice: once from me, once from someone more trustworthy.

Let's say I hack my client to upload specially-crafted packets to anyone that connects. SL is known to crash when it recieves data corrupted in certain ways. This is a more-effective DoS attack, since it uses less of my upstream bandwidth.

Let's say I hack my client to tell me the IP address of everyone who connects. I can now run a DDoS attack on them using a network of zombie machines. This is even more effective, since it uses almost none of my bandwidth.



Teleporting into a server, my average download speed is 1000 kb/s. This is about a third my connection's max, and considering that SL uses UDP, I wouldn't want to go much higher, because of problems with lost packets.

Further, if I max out my upload bandwidth (256kb/s), my download bandwidth will be greatly reduced, since I can't send out packet requests very fast.

my connections usualy just dies if i upload near the cap. Very uncool.

I posted this in the previous topic; I'd also like to add another item:

5) Most people have asychronous connections with very limited uploads, this means it's going to be slower still.

-Adam

I appreciate the constructive criticism. Please keep an open mind to this.

Before going into answers let me give this example. Someone tells me about this cool club in SL to check out. I teleport there, fly over to the club and cant get in. The texture data isnt downloaded yet, I'm waiting a long time to even find out where the walls and entrance to this place is. And then for an even longer time when going inside things are still popping up, when you get close to a texture a more detailed one needs to be downloaded from the server and that takes even longer to wait for. I try to show this off to friends and it takes forever, they're bored by the time its all over. ( and don't say these people who want instant gratification shouldnt be playing SL, Linden relies on a growing user base to continue coming out with new versions for you to enjoy)



If a client receives data from another client that does not match the hash given by the server, the client reports the IP to the server. Server side, for example, if 10 different hosts all report the same host giving bad data, the server stops giving the bad host's IP address out. This allows room for simple mistakes in protocol and also verification of a bad host from multiple sources.



First of all data transferred between clients should be encrypted with a key the server provides. So you're not simply able to create fake packets. Even if you could, throwing out malformatted packets is a very basic function of any network application.



A network of zombie machines you control? This isnt a serious criticism, anyone with a network of zombie machines could ddos anyone else.



Download speed from the server depends on many factors. What I can tell you is Linden isn't going to support 1000 kb/s for thousands of concurrent users and continue charging $10 a months There is a breaking point as the system grows where b/w per user available from the server is going to be sacrificed. No MMORPG out there today uses as much b/w per user as SL does. All the objects come on CDs, and updates come out once in a while. There is no continuous streaming of unlimited data to users like in SL.



An important property of this system is if you take SL as a whole, the number of people flying and zoning around at the exact same time is small which gives them a very stable large base of users to stream from. If this system were in place today you'd find the upload bandwidth required pretty low, as a fail-safe the max u/l can be capped.



P2P is perfect for this, take my club example, 10 people are already there, 1 new person comes in. Imagine how fast it would load for that person if the 10 people with all the texture data already loaded helped out with the streaming.



Prim data, script data is tiny compared to texture data. See my previous post, this is not BT, this is a simple P2P file transfer system, CPU usage is nill, I've coded them, I know. I read the post you directed the reply to, that person had a very shallow understanding of P2P.



If the server doesnt know of anyone with the file, the file is d/led from the server, like it does already. If the client requires a LOD higher than what other clients have it is d/led from the server (and then is available for others)



Yes it does take time to develop, is it worth it? I think it is for both the company and the user. Among all P2P systems I've worked with this one has the most simple design.



I can assure you this systems cpu requirements would be next to nill. Rendering takes real cpu power. Like I explained previously, cache supply would always outweigh the demand, if effect this would require not a lot of upload bandwidth per user. (factor in a in tray u/l system while not in SL and its even lower)



This is interesting, the time to get a texture over P2P might be a couple seconds slower due to request response. But because they are done simultaneously for multiple files it is much much faster than get one texture, get the next, get the next, from the SL server.



Covered this up two paragraphs.


Keep the concerns coming, and I'll keep working with this idea until we're on the same page. I'd love to zone into a popular place one day and have everything pop up immediately and I'm sure you all would too. It can be done.

This is a serious criticism. The way SL works right now, I can't DDoS you -- I don't know who you are. With a P2P system, I still don't know -- but I can make a very good guess. The number of possible IP addresses has just been narrowed from three billion to no more than three dozen, as the most likely source clients are the avatars nearest me. I can now narrow it further by DDoSing the addresses until I see you log out.



I'm not streaming 1Mbps for hours on end, I'm bursting 1Mbps for 15-30 seconds. At this point, I've got all the geometry for the sim in the direction I'm looking and most of the textures have been downloaded.



At the times I'm online and not moving, there may be one other person in the sim with me -- or there may not. In either case, if you're rafting down the river in Davenport, which would you rather be streaming from, a pair of 128kbps sources that are also doing some very CPU-intensive work, or a source with a 10Mbps connection and nothing else to do?

This might be a cool idea in about five years, when lots of people are on broadband connections that have gigabit upload speeds... until then I don't see it happening.

Another issue... LL runs on a skeleton crew... if they don't have time to make text windows and inventory searchable, I really don't think they have time to gamble on some crazy P2P scheme.

By the way, textures load pretty quick for me even when I'm at heavily populated events, while I hear others complaining that everyone's avatar is gray and none of the object textures want to load either. I have a fast computer and that is probably why.

Erm, swax, check your network settings, they default to 300kbps but you can pump it up to a full megabit.