Back in the mid-1990s, while we were designing ViOS as a large-scale commercial server-dependent and massively-multiuser metaverse application, I was deeply concerned that its success as a widely-used platform would be its undoing. Thats because, unlike the web, multi-user immersive environments require relatively constant interactions between clients and servers - and those interactions don't scale well for large numbers of users.
Virtual environments such as multi-user flight simulators and first-person shooters rely on many independent server sessions that are limited to a relatively few users at any one time. Massively multi-user metaverses, on the other hand, require the client to be updated as fast as things happen within the environment. This means that large-scale metaverses need a lot of horsepower in the server layer since every move and every action of every avatar must be conveyed to every client. This puts a tremendous load on a few servers for even the most trivial of interactions. The approach simply doesn't scale to support the widespread global information systems that the Croquet architecture is being designed to make possible.
Our strategy back at ViOS, Inc. was to simply re-tune the system and put up more servers as the loads increased - hoping for the best. That approach would work well for Intranet applications that serviced relatively small numbers of clients. It even worked well for ViOS' initial user base of around 15,000 unique users. Problem was that once we had several thousand simultaneous Viosians tooling about in the landscape, they began to overload our interactivity servers, resulting in performance problems and service interruptions. Since there wasn't a lot of cash flow or investment capital during the 2001 post dot-com financial downdraft, we were unable to add servers at a rate that could meet the demand. If we had, it might have led to another few years of success for the ViOS metaverse platform - but sooner or later we would have been brought down by fundamental flaws in our approach as a bottlenecked client-server based architecture.
The Croquet technology has been developed with these lessons in mind. It is designed to scale in support of interconnected multiverses of millions of users without the need for any dedicated server infrastructure. Croquet's architecture makes it possible to develop metaverse applications in which, anyone can freely put up content in islands of any size, interlink those islands with any number of other islands, and control access to those islands.
By contrast Second Life makes money by controlling who can create islands and how those islands are linked to each other. It also has a very similar technical architecture to that of ViOS - a vintage twentieth century client-server architecture with with single points of failure, inertia, and control. It's been interesting to watch Linden Lab's struggle with the inevitable technical problems faced by Second Life as a result of its recent popularity, constrained architecture, and non-scaling technical approach. For details on some of those struggles click here, here, and here.
5 comments:
Thanks, Julian, for explaining the issue so clearly. When I just started using SL, I was puzzled why there was "black Wednesdays" (SL users should all experienced that Linden Lab used to update SL every Wednesday and sometimes have 6 hours long black out periods) in SL.
Interesting read. As with the internet, SL will have to ditch it's dependence on one source for all it's processing and databases to go forward using tools such as Croquet.
I hope they chose to do so sooner rather than later.
All said well, looks great, but.. in theory. It would be great to see some thousands peers exchanging messages with teatime. What actually makes me a bit nervous is that everybody talks about SL backend architecture without knowing exactly how it is constructed. Recent hints from LL point that they are re-architecturing. In my understanding they managed to migrate to a loosely coupled service-based environment and simulation is separated from other services, like name lookups, transactions, streaming, teleporting, etc. It is clear that LL wants to push itself to use standards for one reason - wide adotption in corporate and mid-to-small businesses after the moment they announce the SL protocol to be _standard_ and after they open the simulation environment (the backend framework, toolchain, simulation). This would practically allow hosting of simulators@office. Now, having in mind WS approach with already stable implementations for most platforms, open architecture, open and standard protocol, wide adoption and the possibility to host your own simulator the way you do with your LAMP, I dont think SL will go down the same way Vios supposedly did. LL admited last-century architecture, no doubt about it, at least they are not sleeping and are doing something in the right direction.
I hope Croquet will really show capabilities to provide scalable environment, and I really admire your efforts, but I dont only agree with speculations and negative aura around competitors before actual test results prove croquet scalability, which as we all know is still quite buggy and more than 10-12 peers make it unusable.
I would be happy to help with testing of croquet for massive scalability, this would sadly not happen before you guys make it more accessible for the average programmer and many people learn smalltalk - yep smalltalk isnt popular and that is a problem not only for individual programers..companies want living eco-system of software solutions and squeak will not have that kind of support in the near future. A workaround would be to provide language bindings, if I recall this being one of your targets in the future. My guess is - do it sooner.
I guess a niche for croquet will be at first application for elearning, which is good, quite good, but aiming at metaverse scale and claiming infinite scalable de-centralized 3D environment and not having any proof for achieved scalability is, to say, unprofessional.
Or, if you have proofs, please post results on the croquet project wiki, i guess many people are waiting for them passionately, including me.
In RL nothing is descrete and mutually exclusive - (!SecondlifeLike)!=(MoreScalableThanSecondLife) and it holds until proof is found to argue it.
So Croquet is based upon a similar notion as the web as we know it? Like anybody can start a server and a webpage?
And with Croquet you guys are throwing over a regime like LL that has total control of the servers, which would make up for quality in theory. This quality being that it's regulated, but they state that there's no realright on anything in their terms of service so that point doesn't quite go up.
My critique of the Second Life technological approach is not an attempt to define Croquet as a competitor to Second Life, or even to imply that Second Life is inferior to Croquet in any way. It is not. Croquet and Second Life are like apples and oranges.
Croquet is an enabling technology for use in creating 3D collaborative applications while Second Life establishes a company owned 3D walled garden in the way that AOL or Compuserve did for the early online experience of many users. As I stated in an earlier posting, the present Croquet SDK is to a future Croquet-based metaverse application as a C++ SDK is to Second Life.
Personally, I consider Second Life to be an exciting 3D environment and valuable experiment in group creativity - regardless of what my experiences tell me about its potential to scale given its present architecture. Much can be learned from the work that Linden Labs has done over the past years. They have built a popular product that has captured the imagination of many. With all the dollars flowing into Linden Labs, I am sure that they will be able to address the current scaling difficulties enough to support numbers within an order of magnitude of its present user base.
Post a Comment