Day: March 26, 2013

SL projects update week 13 (1): server, AO capabilities, HTTP, group ban list

Posted on by Inara Pey

Server Deployments – week 13

On Tuesday March 26th, the SLS (Main) channel received the maintenance package previously deployed to BlueSteel and LeTigre in week 12, which includes a fix for a crash mode  – release notes.

Some issues have been reported on following the Main channel deployment. Regions have been slow to come back up, and several which have had issues with groups and display names failing to show, teleport errors, etc. However, at the current moment in time, these issues do not appear to be widespread.

On Wednesday March 27th, the RC channels should receive the following deployment packages:

  • BlueSteel and LeTigre: a new maintenance package, which includes:
  • Magnum: should receive the same update as the Main channel (i.e. the package deployed in week 12 to BlueSteeel and LeTigre), otherwise retaining the updates and fixes deployed to it in week 12 – release notes.

As usual, there is a forum discussion thread for comments / feedback on the deployments.

That the region crossing fix for BUG-1814 is not been deployed to the rest of the grid in week 13 is liable to cause some consternation.

New AO Capabilities

The new AO capabilities, due for deployment on BlueSteel and Magnum. I provided an overview for the new capabilities in week 12, and the Lab have now provided a set of wiki pages on the calls and permissions:

Ban List – and More

As recently reported, Baker Linden has started working on an update to the code for managing groups which will allow group owners / moderators to ban users who create problems (e.g. those who spam groups, people who are persistently abusive in group chat, etc.).

The work is being undertaken in response to JIRA VWR-29337, and is likely to prove very popular once available.Currently, Baker is working on the development documentation and plan for the work, and has been giving further thought on what the capability will be able to do. Speaking at the TPV Developer meeting on March 22nd, he gave a little more insight into how the capability might progress:

  • A possible format for how the Group Ban option might appear in the viewer, as visualised by Alyssalillian McMinnar
    A possible format for how the Group Ban option might appear in the viewer, as visualised by Alyssalillian McMinnar. LL have an internal design for the UI elements, but this is not something Baker is currently focused on

    The initial release will at least allow group owners and moderators to ban people, a will display the names of banned individuals and the date on which they were banned (presumably to owners / moderators only)

  • It may include a capability to specify why a person has been banned, even if this is initially a case of selecting from a pre-defined list of reasons
  • A future option may be to include a time ban option (although this is potentially more useful in banning people from accessing a region / parcel)
  • An initial design for the viewer-side Group floater has been developed internally by LL, but Baker isn’t so concerned with how the options will be presented through the viewer until after he had defined how the code will work
  • Baker is not planning on adding any on the ban capabilities for group to the existing ban capabilities for regions / parcels, nor will any of the new group ban capabilities be shared with region / parcel ban capabilities, due to the complexities involved.

At the same time as working on the group ban list, Baker has also opted to correct other long-standing issues:

  • The ability to search for people using their user name properly (i.e. no period in between first and last names)
  • A fix for the disallowing of leading spaces on display names.

These fixes will also likely roll-out the same time as the first phase of the group ban list function, once Baker is able to start coding and testing the latter.

HTTP Project

On Friday March 22nd, Monty reported that the Aditi testing had been subject to a couple of non-related hiccups (due to inventory issues), but otherwise the regions were stable and whole one significant bug within the code had been found – severe enough to take down some Apache web servers when HTTP-In was being tested, and which has now hopefully been fixed.

Load testing on Aditi has been a little light, but obviously, more practical load testing will occur when the capabilities reach a Release Candidate channel and things start to get fine-tuned.

Mainland Griefing

The subject of Mainland griefing was discussed at the Simulator User Group meeting on the 26th March. There has been a noticeable rise in object griefing and spamming recently, particularly by the so-called “goonsquad”. Several options for better means of combating the problem were raised, including JIRA SCR-19 (“Script function to return objects”) for the return of griefer objects where users do not have access to estate / region tools for return objects, and possible throttling of llDialog (SVC-8080) to try to overcome the use of dialogue spamming prims.

The Lab will obviously not be drawn into discussions on their own plans for combating griefing, but Andrew Linden took a series of notes on problems which are being encountered, while Simon indicated that the Lab is looking at some options which may help with issues.

Related Links

HTTP updates: the what, why, who

Posted on by Inara Pey

Update March 27th: Commenting on the open-source development mailing list, Monty Linden states: “It looks like Beta (Aditi test regions) will be wrapped up shortly. If you’ve wanted to try these out but haven’t yet, now would be a good time to jump in there.” 

Linden Lab is in the process of making a number of improvements to Second Life which should benefit both the platform and users. Once deployed, some of these updates will be clearly visible as they gain widespread use in-world, such as the upcoming materials processing capabilities. Others will be perhaps more noticeable because they require a viewer update – as is the case with server-side baking, rather than being obviously visible in everyday use. Some will have more of a “background” impact, rather than anything which is clearly visible in-world (although they may make their presence felt for the more keen-eyed).

Monty Linden
Monty Linden

Among the latter category of changes are the HTTP updates currently being tested on Aditi and which will soon be popping-up on a Release Candidate channel. This work is being spearheaded by Monty Linden, and has been under development as a part of the Shining Project initiative kicked-off by Linden Lab in 2012.

Several of my SL projects update reports have covered Monty’s work, and will continue to do so in the future. The aim of this article is to bring the various threads together in a single post, in order to provide a  broad overview of what it all means without getting caught-up in the technical minutiae.

Communications between the viewer and the SL servers are subject to many vagaries. Network issues can occur locally (i.e. with a user’s own network), or at the ISP level, for example, long before they actually involve the SL servers. There is little LL – or the support team for whatever viewer is used to connection to SL  – can do in these instances.

However, network issues aside, there is much work that can be done to improve viewer / server communications and make connectivity between the two more robust – and this is the focus of Monty’s work. Some of this has to do with gradually switching aspects of the service away from the older UDP services within SL to HTTP-based services, and some of it has to do with improving the existing HTTP services employed by SL and making them both more robust and (hopefully) a little easier on older models of routers.

Initial Work

As mentioned above, Monty’s work is encapsulated within the Shining Project, and is being carried out in a number of phases. The first phase of this work was actually completed during the second half of 2012, and focused on improving the HTTP texture fetch mechanism both server-side and within the viewer by which textures are obtained for rendering. This work started to go into widespread use around  November 2012, when the viewer code was made available and Linden Lab announced the new capability thus:

A new scheme for performing HTTP operations is introduced with this release. It is intended to reduce crashes and stalls while performing HTTP operations and generally enable performance and reliability improvements in the future. In this release, it is being used by the viewer’s texture retrieval code. Our expectation is that it will provide consistent and predictable downloading of textures.

The initial HTTP updates being driven by Monty Linden started to appear in around November 2012
The initial HTTP updates being driven by Monty Linden started to appear in around November 2012, with improvements to the texture fetching code in both the viewer and on the server end of things

Following the release of the viewer code, many reported they were seeing significant improvements in texture downloads, and a resultant improvement in texture rendering.

As a part of this initial work, Monty also started examining connectivity between the server and the viewer (number of actual connections opened, etc), and found that it can cause significant hardships for older classes of router, many of which incorporate a firmware-controlled “lock-out” which can be triggered when too many connections are opened when using HTTP, and so can cause users issues (hence the recommendation which some support teams give to disable HTTP textures within the viewer if connection issues are being experienced).

Second Phase

At the start of 2013, Monty commenced work on the second phase of the project, which is currently focused on the server-side of things (that is, there are currently no viewer-side code changes). In particular he is looking at further improving texture and mesh asset-fetching from the server and at implementing HTTP persistent / keepalive connections capabilities, which should enhance the overall robustness of such communications (some of which may hopefully see some connectivity improvements for those people using older model routers, as noted above).

Continue reading “HTTP updates: the what, why, who” →