User:Jesrad Seraph

Jesrad Seraph tries to help with the Architecture Working Group but does not speak English as mother tongue, so technical vocabulary might be off or unusual on this page and in contributions. Work is limited to workflow design, and does not enter debates on underlying technology for transmission, storage or format of data.

General architecture considerations

• Client computers constitute a significant processing power reserve, which has the advantage of scaling with concurrent user number, so any smart architecture design has to tap into it.
• Client's network connections constitute a significant bandwidth reserve, which has the advantage of scaling - on global average - with the concurrent user number, so any smart architecture design has to make use of it.
• Any realistic current or future Grid design involves a large number of computers (large here meaning >64), which puts Grid processing into the supercomputing category of computational problems, so supercomputing best practices are advised as guidelines.

Specific considerations

• Grid processes can, theoretically, be parallelized down to the individual rezzed object, individual avatar, individual script, individual parcel. Each and every of these entities can be seen as a distinct finite-states automaton running in parallel with the others. Making SL scalable is akin to pooling all the resources of the computers involved in the Grid processing (hopefully including, at some point, the clients' computers' processing power) in order to run this Plethora of automatons, so what we're trying to achieve in making SL as scalable as possible is akin to designing on-demand dynamic virtualization for these entities.
• Physics, and specifically collisions, are the one big obstacle on the road to massive parallelization. Current SL implementation mitigates the computational explosion of collisions across the Plethora through geographical subdivision of the Grid processes (Regions), and further geographical subdivision by octrees seperation pre-processing.

My proposal for SL architecture

I've written down most of what I advocate for SL architecture design on the Brainstorming page, under Per-resident subdivision of the Grid as a scaling method.

I'll try to make a clearer, shorter presentation here, using pictures.

Ethics and the designs that make use of client-side processing and bandwidth

Any architecture design that makes use of client-side processing power (distributed processing, virtualization) and/or bandwidth (load-balancing, swarmcaching, proxies) has to take into account the fact that clients are not necessarily willing to dedicate such power and bandwidth. In fact, Austrian economics teach us that implementing proper (as in property-based) enticements leads to a bigger and better managed pool of resources.

Distributing physics: let's not miss the point

The main argument against the distribution of physics processing in SL goes like this: because collisions mean combinatory explosion, and because bandwidth is much scarcer than processing power when treating these collisions, distributing physics means trading processing power use for bandwidth use and causing premature depletion of it, by comparison, making distributed physics slower and less scalable in the end.

I disagree with this view because I think it misses the point thoroughly. The point of Grid processing is simulating an environment for the residents to live their Second Life in, not solving complicated physical simulation computational problems. In simpler words: if making the physics look good is an obstacle to making SL work at all, then off with the physics' head. I view collision/interaction handling as a secondary, best-effort service compared to the rest of SL, and I tend to think the bulk of residents hold a comparable view, as indicated by the fact that LL went as far as implement mechanisms for private estate managers to disable physics and collisions entirely on their land.

Secondly, outside of collisions/interactions the physics can be be distributed down to individual object level just as well as the rest: only dynamic objects which are not already seperated are concerned by the bandwidth limitation evoqued above. Static content is, well, static, and does not contribute to the combinatory explosion.

Lastly, a cascading model for physical interaction could be used, where physical interaction effects are one-way only (not interaction anymore, but action without reaction). This prevents combinatory explosion, too, while still allowing interesting uses (in the Grid resident sense).