Kategorie: Programming

Attack on the grid?

Prokofy Neva and the Second Life Insider are both claiming that the problems we’ve been experiencing with the grid for the last two days are not the result of internal, technical problems but instead of a concerted attack of griefers at the grid.

The exploit used has been reported already at 12th February 2006 and still remains unfixed. They are claiming it is hard to fix, but hey, after more than a year and it being abused to attack the grid, it is time now to do something against it! Neva claims, that the purpose of those attacks is to make Second Life unusable for good use like the Relay for Life event last weekend. Hm, some logic in it, could be, for sure if it was attack this event could have been a worthwhile target for griefers.

What are the conclusions? We are never going to know, if those problems were a gridwide attack of griefers or not, until the Lindens are going to tell us. Some things are clearly pointing into that direction. But if it was a griefer attack, the Lindens should tell so and don’t leave us in the dark about it.

Ajaxlife gone opensource

Ajaxlife, the web based SL chat client, has gone opensource and is available here. While it’s serving its purpose and working, I dislike the fact that it is being implemented in Mono, because due to libsecondlife. If it would be running under another programming language, there would be no need for a sandbox and it would take much less memory on a server, but then again we are all free to do better. 🙂 

Web based SL client in development

There’s now a 3rd party web based SL client called AjexLife in development and available. So far it has more or less the same feature set as Slink, meaning it’s good for logging into the grid, chatting, sending instant messages, getting notifications, viewing the map and teleporting around. Of course – no graphics. The main focus is on for the main client underpowered machines and communicating so far.

Since this works with AJAX, it should be possible that it even works through most company firewalls – I guess the server makes the connection to the grid, not the webbrowser per se. I wonder under which license this work is going to be put under…

Broken friends list

One of the most annoying and persistant bugs at the moment is the broken friends list. This is a very critical feature since many rely on it working properly. Here is the bug for this in JIRA, the open issue tracker of LL, quite an interesting read about it. It goes back into March, quite a bad thing, if you ask me…

Scaling Second Life

In the Avastar #14 there’s a comment of Gwyneth Llewelyn about the scaling of Second Life on page 6. She’s claming that one possible move to relieve the grid of stress would be to store the texture data, which seems to go into the hundred of Terabytes (wonder where she got this number from, I thought all data is around 34 terabytes at the moment according to this article, so I stuck with this number, so hundred of terabytes is wrong on a great scale), from outside the grid, perhaps even allowing users to store them on their own servers. While I don’t see the textures stored on the own servers, because of possible protests, she continues.

She’s stating that if that move occurs the 2000 servers of SL would be able to hold 20 million simultaneous users and this could be achieved within a month with the work of one developer!

Personally, I doubt that – really. I know they’re going to switch from their own data protocol to HTTP somewhat this year. Serving a texture is a quite simple task – provided it’s stored in a simple filesystem and not in a database. Storing textures – binary data – in a database system is always very dumb; the clever way to do it is to store the filesystem name in the database only, since the database is much, much slower to the task and adds far more complicity to it.

And, of course, the textures and so on are really not stored on one hard disk, but I guess on a logical volume or clustered filesystem. There are enough technics around to do it under Linux.

I personally think that serving the textures is not what strains the servers, because they’re loaded into the cache and that’s it, then. It’s more computing the viewing range, making database querys about the prims (if stored in database) with their textures, it is interpreting scripts, computing the locations of all the avatars, doing the physics stuff and so on. And that’s why I think even if the textures are located somewhere else that the technic now available on the main grid is not up to the task to handle 20 million users at the same time