Tag: HTTP updates

SL projects update week 42 (3): viewer, AIS v3, HTTP

Posted on by Inara Pey

The following notes are taken from the TPV Developer meeting held on Friday October 18th. A video, courtesy of Northspring, can be found at the end of this report. The numbers in braces after each heading (where given) denote the time stamp at which the topic can be listened-to in the video.

A typical TPV dev meeting gathers (stock)
A typical TPV dev meeting gathers (stock)

SL Viewer Release Pipeline Updates

The Catalyst RC viewer (version 3.6.8.282367) was promoted to the de facto release viewer on Wednesday October 16th. This viewer was essentially a “hot fix” to address a start-up crash on viewers using the latest AMD Catalyst drivers (13.9, 13.10, 13.11).

At around the same time, the Maintenance RC viewer RC 3.6.8.282335 noted in part 1 of this report as being released on October 14th was withdrawn. It was subsequently superseded on Friday October 18th by a new build,  RC 3.6.9.282553, comprising the same updates: finer access control for estate/parcel owners; CHUI: toggle expanding Conversations by clicking on icon; GPU table update + more.

“ShareStorm” Viewer

Also on Friday October 18th, the SLShare RC (3.6.8.282036) and the Snowstorm contributions RC (3.6.8.281997) were withdrawn and superseded by a new “ShareStorm” RC viewer, version 3.6.9.282535, containing the updates from both.

Viewer Promotions – Time Frame

Due to the volume of work backed-up prior to the implementation of the new viewer release process by the Lab, RC viewers were initially being promoted  to a release status on almost a weekly basis. This has slowed a little more recently, with a promotion to release occurring around once every two weeks (with the exception of the Catalyst RC “hot fix” viewer mentioned above). Barring further situations like the Catalyst RC, the plan is to try to promote an RC to release status around every two weeks.

Interest List Viewer

[01:20 – 22:18]

Richard Linden attended the TPV Developer meeting on Friday October 18th to discuss the upcoming viewer-side changes for the interest list project. He started by giving a high-level overview of the work.

The primary focus of this work has been on scene loading – how things are presented to you when you log-in or teleport to a region. Historically, most of the work related to the interest list has been driven by the simulator. This is not the most optimal way of doing things, and could mean, among other things, that when arriving in a region, you’d start to see things far away from you rezzing first before those much closer to you – so if you arrived inside a house, you’d see the buildings and trees outside of the house appear before the walls of the house would pop into view.

Recent work on the interest list has been aimed towards improving scene loading in the viewer
Recent work on the interest list has been aimed towards improving scene loading in the viewer

So the first part of the work focused on the server end of things. Most of this has already been deployed to the grid, and the benefits can already be felt. There is more structure in how the server sorts and prioritizes data to be downloaded to the viewer, so that when you arrive in a region, the objects which are closer to you or are bigger than others should render first (e.g. when you arrive in the house mentioned above, the floor, walls and ceiling appear before those things outside of the house).

The upcoming viewer changes take this work a stage further, but in more subtle ways.  What is classified as a “cacheable” objects has been changed, for example, allowing the viewer to potentially store more information on objects locally, rather than perhaps depending on the simulator for information relating to them. Additionally, the viewer will be able to retain more overall information relating to a region than is currently the case – fewer “killobject” messages are sent by the simulator telling the viewer to remove objects from cache, allowing them to be re-used rather than the viewer necessarily having to request data on them from the simulator once more.

There are other improvements within the code to assist with better scene loading, such as when you arrive in a region you’ve never visited before (and so have nothing cached). Under the current system, the simulator will send queries to the viewer about every object in the region, because it has no way of knowing if the viewer has data for the region already cached. Under the new code, as the viewer connects to the simulator it will tell the simulator it has no data cached. The simulator can then get on with prioritising the data and getting it downloaded to the viewer, with the result that “several seconds” are shaved from scene loading times.

In other words, to borrow from Richard put it, the updates put the viewer far more in the driving seat with the interest list.

Continue reading “SL projects update week 42 (3): viewer, AIS v3, HTTP” →

SL projects update week 39 (3): viewer, interest list, HTTP, SSA and more

Posted on by Inara Pey

The following notes are taken from the TPV Developer meeting held on Friday September 27th. A video, courtesy of North, can be found at the end of this report. The numbers in braces after each head denote the time stamp at which the topic can be listened-to in the video.

A typical TPV dev meeting
A typical TPV dev meeting

SL Release Candidate Viewers

SLShare

[03:00]

Following my coverage of the release of SLShare, the opt-in capability for those wishing to link their Second Life accounts with their Facebook accounts, A question was asked as to whether the feature would be available to TPVs. Speaking at the TPV Development Meeting, Oz Linden provided comments which answered this question more fully, and and Merov Linden gave further information on the functionality in general.

“One of the design considerations is that this is a feature you [TPV developers] can all integrate without any problem,” Oz said. “All of the actual connections to Facebook, all of the handling of the requisite authentication tokens and permissions and [the] relationship with Facebook itself, is all handled server-side. So the code that’s in the release candidate viewer is something that you can integrate so that you can also make this feature available on whatever schedule you would like to.”

He went on to confirm that given this, no Facebook information for users of the service is exposed to TPVs.

As to how soon it might be before the SLShare RC is promoted to the release viewer, Oz again reiterated that it depends on how well the various candidates currently in the release channel perform. Currently, the metrics for the viewer look good, according to Merov, so it may still leapfrog its way to becoming the release viewer. However it is more likely that it will not become the de facto viewer for at least another two weeks.

Despite the negative reactions to the feature which have appeared in the comments following blog posts, etc., reporting on the functionality, the Lab believes SLShare is already “getting a lot of use”. This view is based on the numbers of people who have pro-actively gone and downloaded and installed the RC viewer manually.

While this may be a case of the Lab greasing the wheels a little bit (downloading and installing the viewer isn’t necessarily the same as running the feature),  Firestorm are reporting that they’ve had at least one request for the feature to be added to their next release.

During the meeting, a series of questions were raised on the feature:

  • Will the feature become opt-out in the future, rather than opt-in? Merov Linden:  “It’s opt-in. We’re not doing anything [behind] the back of the residents.”
  • Will the feature create a Facebook account on behalf of anyone using it? Merov Linden:  “There is no API to create an account on Facebook on behalf of someone.”
  • Will it lead to a merging of the current SL feeds with the Facebook feed?  Oz Linden: ” No, there is no connection between the Second Life profile feeds and the Facebook feed. They have no relationship at all … In theory one could probably build a viewer that did that, but we’re not planning on it.”

(Further questions passed unanswered due to the region in which the meeting was being held being subjected to a griefing attack which left it in a poor state and prompted a change of meeting venue.)

Viewer Statistics

[33:26]

The Lab has been putting together a new statistics reporting system, which is now starting to be used to generate a range of reports. Commenting on some of the information which is coming out of the system, primarily in response to questions asked at both Open-source dev and TPV dev meetings, Oz indicated that:

  • Almost one-third of regions within SL have at least one materials-enhanced object in them, which is described as “dramatically faster” than the adoption of mesh
  • The number of avatars wearing materials-enhanced mesh / prim clothing is “steadily climbing”
  • The number of people who have Advanced Lighting Model (ALM) enabled on a “class 3” (mid-range Graphics cards) or above is just under 20%

One of the problems here – from the Lab’s point of view at least – is that both Singularity and Firestorm have ALM turned off by default for almost all graphics settings, except perhaps High-Ultra, and Ultra. The flip side to this is the view that the Lab enables ALM by default on cards which are barely able to support it, with the result that people’s SL experience suffers through poor frame rates.

In the past the Lab has pointed to data which tends to show that viewers running on low-end graphics cards card do indeed suffer performance issues with ALM active; mid-range GPU show little difference in performance between running with ALM active or not and have “reasonable” fps rates; high-end (“class 5”, as they call them) cards  – e.g. ATI Radeon HD 7800, 7900, 8900, 8950 + similar, nVidia GTX 460/460SE, 465, 550TI, 580, 660/660TI + similar – perform significantly better with ALM active.

The problems here are how one defines “reasonable” frame rates and how one interprets ALM. For the Lab, it would appear that “reasonable” frame rates is anything in double figures – e.g. above 10; many users would disagree with this. At the same time, many users still appear to equate having ALM active with having Shadows enabled (which actually leads to a far larger performance hit), but the two are actually quite separate. As had been pointed out a number of times in these pages, ALM can be active without having to enable shadows.

Running with ALM active does not require shadows to be enabled
Running with ALM active does not require shadows to be enabled

Nevertheless, part of the new viewer statistics system should enable to Lab to gather and present performance numbers for cards with and with ALM enabled, filtered by viewer, so that TPVs can better judge matters for themselves.  In addition, Oz is going to be looking at ways and means of doing systematic testing with cards in order to generate more meaningful statistics, and which may allow for other factors which influcence performance (other avatars in the same region, the amount of movement going on, viewer settings, etc.).

Understanding Viewer Performance

[45:41]

A further problem with the viewer is that it is complicated, and while there are many tools to help monitor performance, people either focus on the wrong tools or cannot find those that would be helpful to them in diagnosing an issue when they do encounter unexpected performance drops.

To this end, Oz floated the idea at the TPV Developer meeting for TPV devs to give thought as to which tools and information feeds within the viewer would be useful to users to help them understand what is going on, and how best to present said tools, etc., in a way which would make sense to users and enable them to make use of the information they are seeing.

Continue reading “SL projects update week 39 (3): viewer, interest list, HTTP, SSA and more” →

SL projects update week 36 (2): Server releases, viewer, HTTP

Posted on by Inara Pey

Server Deployments – Week 36

As always, please refer to the week’s forum deployment thread for news, updates and feedback. Deployments are a day behind the usual schedule due to the US Labor Day long weekend.

  • On Wednesday September 4th, the Main channel received the maintenance package deployed to all three RC channels in week 35, which includes Preparatory work to support new estate and parcel access controls and the new manual region restart capability which sees a region restart as soon as the last avatar leaves (release notes)
  • On Thursday September 5th, the three RC channels received the same maintenance package, which comprises  server-side HTTP updates which require a future viewer-side update. In the meantime, these changes should not be apparent in any current viewer release (release notes – BlueSteel)

Upcoming Server Deployments – Week 37

It looks likely that the HTTP updates deployed to all three RCs in week 36 (of which, more details below), will go back to just one RC in order to make way for additional packages “to get the server flow going again”.

Speaking at the Server Beta meeting on Thursday September 5th, Maestro Linden provided some information on some of the updates expected to go to at least one RC in week 37 (week commencing Monday September 9th):

  • The llXorbase64 issue reported on in my week 35 (2) report for details
  • A fix for an issue where an avatar sitting at high altitude may appear to be located at 0,0 on both the world map and mini map
  • Nerfing of recursive rezzing. Again, this was outlined in my week 35 (1) report. Under the new code, the copy of the original object will inherit the temp-on-rez and parcel time of the originating object and so be returned at the same time.
  • Fixes for a number of JSON function issues, including:
    • JSON implementation treats blank string and JSON_NULL interchangeably
    • Issue with llJsonSetValue with strings that end in ‘]’
    • RFC 4627 Non-Compliance by llJsonSetValue() with out-of-range Indices

SL Viewer News

There were no changes to the SL release viewer this week, again most likely due to the long weekend in the US.

Snowstorm Project Viewer

As reviewed earlier in the week, there has been a new Snowstorm contributions project viewer released, which includes various fixes and Jonathan Yap’s request teleport feature and a port of Cinder Roxley’s “eject from group confirmation” pop-up.

New request teleport capability - Snowstorm project viewer
New request teleport capability – Snowstorm project viewer

Interest List Viewer

Delays continue with this viewer, largely as a result of bug stomping requirements. Commenting on the situation at the TPV Developer meeting, Oz Linden said:

As you might imagine, monkeying with the interest list is full of opportunities for errors; and I think the team is really sensitive to that and trying hard not to have a bad launch. I keep hearing status updates from them, but none of them have been, “We’re going to launch the viewer right away”.

Hoz Linden then added, “They honestly are really close on the interest list, but there continue to be a string of bad bugs that need to be fixed.”

Animation Override Interface

Viewer-side hooks for LSL AO capabilities in the future?
Viewer-side hooks for LSL AO capabilities in the future?

As reported in week 34, Oz Linden is looking-in to the possibility of developing a viewer-side API / hook into the LSL AO capabilities introduced server-side earlier in 2013. Initial discussions with the Lab’s own developers seemed to go well (or as Oz put it at the time, they didn’t run screaming from the room…

As Oz will shortly be in San Francisco in the near future, he’s going to poke some more at the idea with the people at Battery Street and “see if there is something we ought to be doing.” Again, this is still a nascent idea, even with the offer of import from Kitty Barnett, and Oz went on to say:

If this is going to happen, and it is still a major league “if”, I think we would want to do it as part of a project in which a substantial improvement was made to how the viewer interacts with animation in general, and that means I would want a set of open-source devs involved in doing the viewer-side work. So be thinking about whether or not you can commit to that.

Continue reading “SL projects update week 36 (2): Server releases, viewer, HTTP” →

SL projects updates week 36 (1): server releases, HTTP notes, anti-griefing

Posted on by Inara Pey

Server Deployments

As always, please refer to the week’s forum deployment thread for news, updates and feedback. Deployments are a day behind the usual schedule due to the US Labor Day long weekend.

Second Life Server (SLS Main) Channel – Wednesday September 4th

The Main channel should receive the maintenance package deployed to all three RC channels in week 35, comprising:

  • An update to region restarts initiated by region owners or estate managers which will see the region restart after the last avatar leaves, rather than waiting for the full countdown period to complete
  • Preparatory work to support new estate and parcel access controls – these will require an upcoming viewer-side update in order to be visible to users
  • A fix for a physics-related griefing mode (see below)
  • A crash mode fix.

Release Candidate Channels – Thursday September 5th

All three RC channel should receive the same maintenance package, which comprises  server-side HTTP updates which require a future viewer-side update. In the meantime, these changes should not be apparent in any current viewer release. The updates specifically comprise:

  • When connections between viewer and web services were closed by the server, the last response was sent without a ‘Content-Length’ or ‘Transfer-Encoding: chunked’ header. Last response will now be sent with ‘chunked’ encoding.
  • Throttling actions on Capabilities URL result in 503 status codes back to clients. These responses may include a ‘Retry-After’ header with a delta time giving a hint as to when the client may retry the request. In the absence of such a header, client is expected to make ‘reasonable, best-practices’ delayed retry attempts.
  • Adds support for a new capability, ‘GetMesh2’ for fetching mesh assets with keepalives enabled.

HTTP Notes

The RC deployments look to be the first part of Monty’s continuing work on HTTP connectivity between the viewer and the SL servers. As noted in recent reports, the core focus of this work is on improving mesh fetching capabilities between the two, although Monty is also working on a number of other updates, all of which are aimed at improving the HTTP services between the viewer and the SL servers and making them more robust, as well as paving the way for HTTP pipelining in the future.

Group Ban Lists

Baker Linden continues to work on the new group ban list functionality. The focus is currently on the UI hook-ups and back-end validation checks. It will still be a while before a project / RC viewer is likely to appear, but hopefully not too long.

Anti-griefing Work

Andrew Linden continues to work on “anti-griefing” measures, reporting that the “physics-related griefing mode” which forms a part of the Main channel deployment and which is already on the three RC channels, is to prevent the use of “faux rotating megaprims”.

These are megaprims which used a physics collision exploit to knock avatars out of that region using the ‘resolve interpenetrating objects’ collision logic. “We had  some collision-bypass code there specifically for avatars, but it had been broken some time ago,” Andrew explained, the break apparently allowing the exploit. He’s now fixed the code breakage, and reports from a number of RC sandboxes is that it appears to have worked.

Other Items

There was a report made during the Simulator User Group that some LSL events are failing to execute or aren’t being queued / cued when a script is caught in a loop. details were sketchy, but a BUG report was due to be raised.

SL projects update week 34 (2): Server, viewer, group ban list, HTTP

Posted on by Inara Pey

Note: with the exception of the server deployment review, the majority of this update has been taken from the TPV Developer meeting held on Friday 21st August. A video of the meeting, recorded by panterapolnocy, is available at the end of this article

Server Deployments Week 34

As always, please refer to the week’s forum deployment thread for news, updates and feedback.

  • On Tuesday August 20th the Main channel had Server-side Appearance (SSA) enabled, as per this blog post from the Lab.
  • On Wednesday 21st August, the Magnum RC received a new maintenance package with “under the hood” changes which should be invisible to residents, while BlueSteel and LeTigre received an update to the package deployed to BlueSteel in week 33. This includes a fix for the “grey box” attachment issue which affected multiple avatars riding an object over BlueSteel region crossings. Additionally, these channels also saw SSA enabled, meaning the entire main grid is now running SSA.

SSA Update

For information on the Server-side Appearance deployment, please see my separate report.

SL Viewer Updates

A new release candidate debuted on August 20th with the name “CHUIStorm” (3.6.4.280048). This is a merging of the CHUI and Snowstorm RC viewers with the latest de facto release code base. The reason for merging the two RCs is because the Lab felt there were “too many RCs in flight”, making it difficult to determine which one should be promoted to the release viewer if several appeared ready simultaneously. In future, the Lab hopes to keep the total number of RCs in the channel to around two or three.

Interestingly, the Google Breakpad RC has vanished from the list of RC viewers in the Release channel.

The Materials project viewer was promoted to the Release channel on August 21st (RC 3.6.4.280083), leaving the current total number of RC viewers in the channel at three (CHUIStorm, Cocoa (Mac) and Materials).

Next in the Pipeline

While the order in which they appear or the overall time frame for their release is not clear, there are a number of project viewers which will be appearing in the near future. These include:

  • A further Snowstorm project viewer (third-party developer contributions) – currently with LL’s QA team
  • A new Interest List project viewer (which has had trouble passing QA – see below)
  • A further SSA project viewer – for details see my SSA Update
  • A Group Bans project viewer (see below)
  • An HTTP project viewer (see the HTTP update below)

In addition, Oz Linden hinted that he may have a surprise announcement at the next TPV Developer meeting in two weeks. While he said absolutely nothing further on the subject, the resultant speculation was that he might have been referring to the arrival of an Experience Tools project viewer. Linden Lab accidentally exposed such a viewer a few weeks ago, but quickly moved it back to a private status, so there is an awareness that a viewer is in development. Whether the speculation is right or wrong will be revealed in the fullness of time!

Interest List Update

As noted above, the viewer-side updates to the Interest list project continue to evade a project viewer release, but are expected to appear “soon”. While the code does not contain any mandatory changes TPVs must adopt, there are obviously optimisations within the code which will be beneficial for TPVs to pick-up once the repository is public.

Group Ban List

Baker Linden continues to make good progress with the group ban list project. He is currently working on what he sees as the last major part of the initial work: getting the viewer connected to the server. After that, he reports he has “a lot of security checks, and some minor additions”. There’s still no date for a project viewer, but it would appear that it is not that far from reaching a status of “real soon now”.

HTTP Update

Monty Linden is continuing to work on his HTTP updates, although he has most recently been trying to get the ” bureaucratic details” sorted and getting a QA pass on both the server-side and the viewer side work. He’s also trying to get a DNS fix in as well, which he describes as the “great DNS look-up failures problem” which the Lab has had for a number of years. He thinks he has a fix for the issue, but he’s not 100% certain.

Monty's HTTP work is now focusing on mesh connections
Monty’s HTTP work is now focusing on mesh connections

In terms of the HTTP work, Monty is trying to get a project viewer lined-up, and describes the major feature within it as being the reduction of the number of connections used by mesh so that it will be possible to start using keepalives  with mesh as well.

As I’ve previously reported, Monty has already reduced the number of mesh connections from 32 to 8. Going forward, eight will be the new default (rather than 32), with the aim being to cap the total number of mesh connections used by the viewer, with adaptive throttling and two different re-try schemes. The hope is that this will further improve network utilisation by creating more effective viewer / server connections; it should also help less capable routers.

Continue reading “SL projects update week 34 (2): Server, viewer, group ban list, HTTP” →

SL projects update week 32 (3): all things viewer, SSA, HTTP and more

Posted on by Inara Pey
A typical TPV dev meeting
A typical TPV dev meeting

The Viewer Release Process and Viewer News

There are currently five viewer release candidates sitting in the viewer release channel. These are:

  • CHUI updates
  • Cocoa updates for the Mac version of the viewer
  • Google Breakpad updates (fixes and updates to improve the level of crash reporting from the viewer)
  • Maintenance viewer updates
  • Snowstorm updates (third-party contributions to the viewer)

As the first release candidate has now become the de facto viewer release (the Vivox updates, see part one of this report), all of the remaining release candidates are undergoing rebuilds using the “new” release viewer code base, and this is expected to be completed in week 33.

The current number of release candidates is considered to be atypical of the process, and reflects the fact that there is a backlog of viewer updates to be cleared. Once this has happened, it is anticipated that the number of release candidates within the viewer release channel will fall. In the meantime, it means we could be seeing new viewer releases (i.e. release candidates being promoted to the de facto release viewer) at the rate of one a week, depending upon how well individual RCs perform in user testing, until such time as the number of RC viewers becomes more manageable.

Installing Multiple Release Candidate Viewers & the Auto-updater

By default, release candidate viewers are intended to install / be installed into the same location as the de facto release viewer. Therefore, if you wish to run multiple RC viewers, you must install them manually into separate folders.

However, there is a problem in installing multiple RC viewer under windows, whereby the last location used to install a viewer is recorded by the installer (presumably as a registry setting), and the auto-updater will automatically use that location to install any update. So, if you manually install “Release Candidate B” into its own folder, and then receive an update for “Release Candidate A” (already installed on your PC) via the auto-updater, it will be installed into the folder containing “Release Candidate B”, overwriting it. This may even happen if the auto-updater is “disabled” within viewer preferences (see here for notes on how to avoid this).

At least one JIRA (non-public BUG-3522) has been raised against this issue. However, while LL are still investigating the problem, if it lies within the installer itself, it may not be addressed as there is an unwillingness at the Lab to get deeply involved in the mechanics of the installer.

Viewer Downgrades

There have been reports of the auto-updater mechanism forcing people to downgrade their installed viewer to an earlier release. While it “shouldn’t happen”, and may have been fixed, anyone who does experience the problem when auto-updating a viewer is asked to raise a bug report with as much information as possible on what happened (i.e. version being run before the update, version running after the update, date of update, etc.).

Making the Viewer Management System Available to TPVs

The Lab is experimenting with making the viewer management system available to TPVs if they wish to make use of it. This will mean that TPVs will have to port the code for use in their own viewer / environments, but it could help them with automating viewer updates if they don’t already have such a mechanism in place. One of the potential benefits of this for those TPVs following the Lab’s lead is that, as a result of changes also being made to the Lab’s reporting mechanisms, they will be able to receive a range of stats reports on their viewers directly from the Lab.

Settings.xml Changes

The current Snowstorm release candidate includes a change to how the settings.xml file works (the file which controls your viewer settings). This change will only affect those who have more than one Linden Lab viewer installed on the same computer (for example, someone who has the release viewer, a beta viewer and several project viewers installed), and will see all of the installed LL viewers using the same settings.xml file, rather than each creating a separate version of the file. This should prevent issues where the settings from one LL viewer are incorrectly applied to another, as can sometimes occur at present.

Interest List News

As noted in earlier parts of this report, Andrew Linden has wrapped-up his current work on interest lists. However, the project viewer for some of the work still has yet to appear, and is apparently still encountering problems getting through LL’s QA process. The code has been “real close” to being ready for release in some form on a number of occasions before getting kicked back for further work. The hope is that it will appear as a project viewer – or possibly a beta or release candidate – “soon”.

Continue reading “SL projects update week 32 (3): all things viewer, SSA, HTTP and more” →