Those who read this blog know I try to report on the various LL projects which are on the go, both server-side and viewer side and – in some cases – both.

One of the latter is the HTTP project work, which has been in progress over the last couple of years and spearheaded by Monty Linden, who has been slowly but surely making dramatic changes to SL’s sometimes creaky communications mechanisms. This work started with texture fetching, way back in 2012, and has steadily progressed from there, with changes being made both server-side and within the viewer.

Much of this work has gone unsung among the greater populace of SL as a whole, which is a shame, as Monty is perhaps one of the great heroes of SL and the Lab for taking-on this work and developing a project and roadmap which not only massively improves viewer / server communications and their overall robustness, but which is also having beneficial impact elsewhere (such as Monty rebuilding third-party libraries critical to the viewer and putting in place mechanisms to ensure they are properly maintained going forward) and also preparing the ground for HTTP pipelining.

Most recently, Monty’s work has involved overhauling the way in which mesh is handled between the viewer and the server (both uploads and – in particular – downloads), something which has been an issue since mesh was first introduced, due to the manner in which it effective “shotguns” the network, and also because – to a degree – people don’t fully understand the impact certain debug settings have on viewer / server communications.

The fruits of this labour have already been released server-side, and now the viewer changes are reaching a point where they will soon be filtering into viewers of all flavours, the code having now moved from a project viewer to a release candidate viewer.

(This viewer should also address the DNS problems many users have experienced and eliminate the need to use the Google DNS workaround for those who have been affected.)

The blog post is a careful and clear explanation of the work which has gone on to date, covering all aspects of the project, the positives and some of the negatives, while touching on some of the complexities of viewer / server communications which are outside of the Lab’s direct control, but which these changes may well still help alleviate to some degree. The piece also looks to the future and what also might be folded-in to the work, allowing for management decisions, staffing, and other priorities as well. While the look ahead is somewhat speculative at this point in time, it does point towards some intriguing options, such as updates to HTTP services such as inventory operations…

All-in-all, the post is a worthwhile read for anyone with any interest whatsoever in the work the Lab is putting into trying to improve Second Life and improve the experience for all of us who use it.