Blessed Be

HTTP over TCP is also a thing well managed by many devices/routers out there. They can learn and keep track of TCP flows easier than UDP ones. Add Early Congestion Notification (ECN) that is available within TCP, you'll get lower packets loss (less data to be sent from LL's servers). Maybe even flag the flow with some Quality of Service (Hmm, good luck with ISP though).

And don't forget all the tricks from HTTP 1.0 and beyond: Not only persistent connection but multiplexed connections (Hey. let's pause that download of that far texture to get the one that just poped a inche from your nose). Fine granuled caching (what and when to flush things from cache to maximise the cache hit ratio) and big disks spools (hey, 1 gig client cache is good but maybe your ISP have a multi-terabytes transparent caching, let's us that too!). Tools like reverse proxy (Squid is GPL) and content delivery devices could also be used at LL to shield the asset server from the load (À la Akamai or Cisco) that handle HTTP off the shelf but not the LL's UDP protocol.

Edit: Hey, don't want to sound like a Mr-know-all but I work and the field and sometime wishes I could play with the high end stuff... *sniffs* I want a raised floor too, that guy at Big-Data-Center-inc have one!

There's probably a good reason for that.

Oh, I just like arguing technical points anyway. I know Second Life will never be anything more than a game -- yes, a game, because I refuse to call anything without file handles a platform. However, I also know people from Microsoft hang out here, and they do have a pretty good grasp of technology. My goal isn't to really win arguments, it's just to be loud, annoying, and offer a different viewpoint on how the system could work in the hopes I might get hired when the real Metaverse takes off.

That's how it worked in Snowcrash anyway.

It might be, but how would you solve the caching problem?
I hadn't even thought of that.
Gee, I was suggesting that wholly replacing UDP with HTTP for bulk transfers would be good.

Thank You, Captain Nonsequiter.

What the hell does that mean?

That should say, "without filehandles." Sorry.

Ah, so that excludes Microsoft's abominable socket library. Good to hear.

I like it personally, as an option, not a replacement for the current system. Basically for two reasons:

1. There are LOT's of people here who couldn't or wouldn't want to host a webserver.
2. ISP's like my cable company that block web traffic as soon as they detect thhat I have a website up. I don't think everyone wants to pay for a hosted website.

Who considers winsock.dll a platform?

On second thought, I take it back and will admit that I was both wrong and rash back on page two. Second Life is a development platform, it's not just a game.

The problem is, it's a very limited platform, it's like trying to develop the WWW by starting out with AJAX instead of CGI -- this idea is not orginally mine. Second Life, as far as software development platforms go, is all flash and very little substance. We have 3D graphics and streaming audio, but there's no programmatic persistent storage.

This isn't a new argument, but for the sake of this argument, that's why I made that snap statement back there. It's so much easier in Second Life to perform acts similar to trade crafts in MMOG's -- things like house building, vehicle driving, and clothes making -- than it is to perform simple, platform development acts -- such as writing to a file, grabbing a webpage, etc.

Yes, Second Life is a platform, I retract my original statement. It's not a good platform, though, and it's certainly not as robust and discrete as LAMP, AJAX, .NET, or Perl. It lacks so many things (which, yes, can be potential security threats) that would make it so much better; it lacks so many simple things that so many other development platforms not only have but are also taken for granted.

Just kicking some ideas around in my head... Other people have probably brought up the same idea.

Lets think about something maybe a little different? Why not create a distributed data management system (DDMS). First, all assets - images, scripts, ojects, etc. - are given a global unique ID (GUID). We'll need this GUID for all of this to work. All servers and clients have their own asset server.

This GUID is a unique value composed of the asset's servers address, date/time, avatar's name that made the asset, etc. Basically, you can never create an asset with the same ID again on the same server or anywhere else. A copy of an existing asset is given a new GUID.

On clients, the asset server replaces the current cache system. It's a lightweight asset server that is optimized for speed that starts with just the textures and objects that compose your avatar and everything else in your inventory. (This might also make it easier to offer the availabilty of offline storage for objects created by you). When you visit a sim or another avatar approaches you, their assets are then loaded into your client's asset server. When they are no longer needed (their avatars are no longer in range or you are no longer in the system), the assets are purged after a fairly short amount of time.

When your avatar enter a sim, the server containing that sim requests all the objects from your asset server that compose your avatar. The server then caches them for any other client. Depending on how common sim crossing is (versus teleporting every where), the server can then send your assets to the servers for adjacent sims to pre-load your assets into their cache. After a certain period of time the assets their cache is expunged with pre-loading cache being purged after a shorter interval. It's an asset splash cache system.

As for objects such as buildings in a sim, their assets are stored on the server that contains that sim. The asset splash system might be ultilized here too to allow a rerundant copy of assets for disaster recovery and to preload them as players approach a sim border.

Now when you visit a sim, your client request all assets within range. You client will take it from whomever responds first whether they are a client or a server. Odds are a server will respond first. But in certain conditions where a server may be extremely busy by running scripts, clients can help performance load by taking up some of the slack.

The "one, true asset server" goes bye-bye. Why-oh-why, LL thinks that is scaleable is beyond me. The history of the internet refutes that idea.

And on the bright side in a DDMS system, if the LL offices blow up, you lose only the assets that were in the sims that were hosted on servers located there. Opps, that's everything right now, oh nevermind. But in the future (if) when SL servers can be hosted anywhere, if LL offices got stomped on by Godzilla then the rest of SL would continue with some losses. Well provided you could log in still.

Well, see, a dataserver key functions like a file handle in LSL. Yeh, you can't do read and write on it... but you can't do read and write on all the file-handle-like things in Windows either.

I have been anxiously awaiting the advent of textures from the web for quite awhile - it opens up all kinds of inworld possibilities for Snapzilla and other projects I am working on. I am excited to hear there will direct HTTP methods to communicate with a site - right now, having to use email to trigger a script on a web site is clunky and annoying. I am curious how they will handle the incoming response, but that remains to be seen. The tighter the integration with the web seamlessly, the more possibilities it opens up for richer communication and presentation in SL.

Hmm... Well, I never thought of a primary key as the same things as a file handle, but according to you and Wikipedia it is.

I'll be more painfully specific next time... But you can at least do read/write on a good many "file-handle-like things" in Windows.

A file handle is just an opaque object that you can perform file I/O operations on. In LSL there's two file-handle-like objects: channels (which are similar to Fortran logical units) and UUIDs. Of course you have two separate APIs for the two sets of handles, and the quality of the implementation is one of the lowest I've seen (it's worse than Windows or traditional DEC operating systems) but at least you don't have to hand-craft packed file control blocks like you used to do back in the bad old days.
The quality of the implementation on Windows isn't super good, but it's better than on VMS or RSX-11 (let alone LSL), but having multiple APIs and sets of file handles is one of the things I'd hoped I'd left behind in the '80s when I was finaly able to switch back to UNIX from VMS.