SL for Low Speed Connections

This is not only intended for dial-up users. Also Satelite and Wireless users would benefit from this as all 3 have issues running SL. Dial-up is pretty much SOL when they first start up but with this implemented they could actually function in SL, as more than a chat room. Satelite and Wireless users have high speed connections but have delayed transfer causing everything to be 5 - 10 second later on larger transfers. On with the Idea.

I was thinking of a way for SL to expand to include dial-up and other low speed connection users. In this Linden Labs can reduce there monthly bandwidth expences overall, reduce latency issues some encounter by constantly re-downloading files and be able to offer service to people who do not have the high-speed internet that is pretty much required to be able to function in SL.

Its a basic and simple Idea actually I have seen posts on it before but never saw the reason why it was not adopted.

The Idea is to implement a ONE-Download System. Dont worry this does not mean you download a huge installer with all the data from the server database in it. What it means is you download the same small 30MB - 40MB client and connect as normal. However instead of having a Cache built to hold Temporary data about objects/clothes/gestures/scripts from in game you have a folder setup to contain a Database that hold Permanent Updatable data of the information.

You see All objects in the SL database use a certain format for the database. This is used for the client to be able to tell the database what files are needed for it to display the scene to the end user. It is a pretty simple. Probably something like the below examples.
#root#/clothes/shirt/(clothing-ID-number).(extention)
#root#/clothes/pants/(clothing-ID-number).(extention)
#root#/genetics/shape/(genetic-ID-number).(extention)
#root#/images/snapshot/(image-ID-number).(extention)
#root#/images/texture/(image-ID-number).(extention)
#root#/objects/multipart/(object-ID-number).(extention)
#root#/objects/singlepart/(object-ID-number).(extention)
so on and do forth examples are just for example. I have no idea what the format actually is.

In most operating systems you can save files with a version number so if an entry every gets updated on the database the client will see that it has an older version of the file when it is trying to access it and overwrite the old data with the updated data. This is done as needed instead of overwriting it everytime you log into SL like it does in the cache system.

The Idea is to update the client to be able to build a clientside database. lets say
C:/Linden Labs/SecondLife/ - holds the current client build
C:/Linden Labs/SLDatabse/ - hold all the database files that have been downloaded to clientside.

With this setup it brings the clients to a one download system. Now the client itself remains as just the data needed to connect to the grid. Once In the grid you encounter objects/people/clothes etc etc etc and the clients performs a quick check to see if you have that data in your database. If you do the client loads it from the localdatabase instead of downloading it. If you do not then the client downloads the data from the remotedatabase to the localdatabase. This will lessen the load on the server databases. This works much like the cache, however with the database you are not stuck getting files updated every other day because the cache forgot where the file was.

Oh yeah have a place where the end user can set a maximum size alotment, with this they can keep from overfilling there PC with data. When the alotment is almost full. The client would delete the files that have been unaccessed for the longest period to make room for the new files.

This could even be an option in the client. FileSystem - Database or Cache depending on the type of connection the end user has they may prefer a cache as it gets cleared out regularly.

I know my explination is not the best explination in the world but it does get the idea across. If anyone else has anything to add please do so.

Oh and this is not completely my idea I have seen someone post about something similar once before but I could not find it when I wanted to see what the responce was. The old idea was something like making all the data be downloaded constantly while online until you had the whole database. Well that in my oppinion is a waste of end user space. The end user only needs the files that they actually run across. In the idea I based this from everyone would have a huge database and by most standards would never access 10% of that in the game world.

Being as SL is constantly having new things created and added to the database this would be the only way someone with a lower speed connection to enjoy SL. And before you start the just get Broadband. There are actually places where High Speed is just not Possible. Personally I have had to move to one of those areas and gave up on SL at that time. So hopefully this can be a possibility. I have tried every avenue to get high speed connection, and there is literally no possibility in my area.

I hope this idea comes to be a reality as I would like to get back to hanging with my old friends in SecondLife. And heck even if this idea doesn't make it easier for slowpoke connection users to get more functionality out of SL. It will make the overall monthly bandwidth usage of LL drop drastically.

Cheers
Flashing Dagger

PS The main difference between the database and the Cache other than how often its cleared is that the database actually formats the data into folders/files.ext instead of how the cache throws everything into one big folder which really causes major lag on weaker PC's.

Really a better caching system is a big must-have for the client in general, not just for dial-up or high latency connections, the current cache is prone to corruption and far too limited in size for the sheer scope of data that is out there in SL. I can't teleport between two sanely built places without having to reload everything there. I have a good 160gb of free space, why limit me to 1gb?

One suggestion I saw a while back that I liked was for the client to have colour approximation of textures. Basically, instead of receiving a texture in full, your client will just receive the averaged colour of the texture (ie if it's most blue and part green you'd get a green-blue colour).
Sure, the world becomes a flat colour based world, but it means that objects can take on an appearance much more quickly, rather than being flat-grey as they are now. Textures would still download, but until they are ready the colour will show you what you need.

Add onto that a way to determine what portion of your bandwidth should go to textures versus object updates etc, and you could very easily have a client that performs playably even with low bandwidth.

However, I hasten to add, regarding dial-up (or low end broadband) versus high-latency. There isn't much to be done to improve high-latency connections, as textures download perfectly fast, the issue is that there's a slight delay before they do. The real issue with high-latency connections is in avatar movement, which unfortunately can't be improved much.

with this it would actually increase the speed a bit for high latency connections as well. Maybe not to what a cable connection does but in a since it would.

The First time through the End-user would move pretty slowly. Because the objects/textures have to load but once they are in a permanent cache (whatever upgrades will help in this area), the end user only has to transfer data about movement. Thats a very small packet and only causes a minor delay. But if the packet is movement + objects + textures + streaming music + particle + etc etc etc etc. the packet tends to cause them to have a 5 - 10 second delay per step. So its still a slight improvement.

Whatever the change they can make it a selection in the options that each user chooses the method they want there client to interact (permanent cache or temporary cache/and with the advanced cache the user can just select the size they want allocated).

If its only giving the user the option to have a larger cache that wont fix anything. The main problem with the current cache is that it is all in one big folder. The client is having to search through lets say 10000 files to find the ID its looking for instead of being able to look right in the folder that its supposed to be in and only searching through 500 files. A folder based cache would make a world of difference.

Giving the user the ability to select there size would help as well. Personally I have a whole 1 gig slave drive thats able to be used for nothing but an Second Life Database. However I am stuck in an area that the best I can get is Verizon High-Speed Wireless. Which has a pretty good size delay as it seems to chunk everything together in large packets. Which causes me to seem like I am on dial-up.

However Thanks for the input Haravikk Mistral I am glad to see that other people want this to be addressed also. And hey I don't see how LL can argue with this one. It would even help them to lower the Bandwidth, which could actually cause some of the high lag Sims to stop falling off of the grid. Since the Sim doesn't have to access the Asset Server so much its more capable of handling its load.

Cheers
Flash

If I'm not mistaken, the "high latency" in high latency connections is the high transfer time of packets. I.E. I hit a movement key and 4 seconds later my avatar moves. Having pre-loaded every texture in the region AINT GONNA FIX THAT.

LL makes money selling server space. I'm not too sure they would be interested in cutting bandwidth need no matter how much richer the experience would be for the user. They could at least give us offline access to our inventory. Lots of us would like that. It's been mentioned many times. But it's in their self interest to have as many people churning as many GBs as possible. There is hardly anything SL related that you can do outworld even though it's very feasable. I'd like to keep my inworld experience rich and do inventory shuffling offline.

I like your idea very much, but will LL try it?

Cutting bandwidth wouldn't affect that, LL make their money from people needing the server-space to build places. The more people they can get doing that, the more money they make. Less bandwidth use would mean less downloading for users and thus a better experience. Just because we have broadband connections doesn't mean we should be downloading the same textures over and over every moment we're on SL, less bandwidth use could make for much faster rez-times of your most commonly visited places.

I'm still not sold on the high-latency issue being fixed, unless avatar movement prediction was done better on the client I don't see there being a solution to that.

But better caching would certainly mean less strain on your internet connection, and thus faster rezzing areas and a better experience. Bandwidth for LL may be extremely inexpensive, but there's no sense in constantly throwing textures around that could have just been saved on the client's computer the first time around.