Oz Linden has put up a link to a new HTTP Project Viewer. You can find it in the SL Wiki on the Second Life Alternate Viewers page.
Part of the Shining Project is improved client/server communication using HTTP. Redoing the HTTP coding in the viewer and servers is the project. The stated goal is:
The start of a unified approach to HTTP-based communications between the viewer and grid services with a goal of achieving reliability, consistency and a better overall experience on the grid.
This project viewer has some of the changes the Lindens think will improve things. They are looking for bugs, gathering data, and asking for feedback. The project viewer will allow people to help out.
…if you have had problems when you enable the use of HTTP, we would very much appreciate your giving this a try. We know that it does not yet solve all the problems, but we think that it solves some and provides the first steps needed for solving some more in the future.
If you are one of the people that have had problems with things rezzing slowly, inventory failing to load then this is something that may help you or, at least, get the Lab the data they need to fix the problem.
Comments from early testers have started coming in:
On Windows 7, the difference was much more dramatic. Mainstream viewers have been painful and jerky for a long time on that machine even with HTTP textures off. This viewer is running firmly on the “I can live with this” side, even with HTTP textures enabled. Flying around in some heavily built areas was even tolerable.
However, some are noticing warning messages flooding the viewer log.
Singularity Viewer has alternate code that works with the new server side code. It is supposed to be even faster. Expect the speed to be in rez time not FPS. The bandwidth is hiting 1 mb/sec.
Henri’s Cool VL Viewer has different HTTP code and with tweaking is hitting 2 mb/sec.
Much of this development involves learning what people do and how the new HTTP channels are handled by the SL servers. The Third Party Developers are seeing the SL Servers as much like web servers, capable of numerous connections. The Lab is leery of that and planning on few connections. We’ll see how that works out as time goes on. The Lab is planning experiments to find the best settings and ways of doing things.
TCP connections, which HTTP uses, deal with communications congestion. As things get congested and packets of information are lost, TCP is designed to halve the transmission window to reduce congestion. That means as you have more connections, pipes, the likelihood of collisions increases. Your are getting more data really fast. But, a collision cuts the speed in half. Some where there is a balance point where one can avoid collision and run at full speed. Going to either side of the balance point results in less data being moved.
Speed is not the only consideration. Users’ routers are another issue to be handled. Older and/or cheaper routers can have problems with numerous connections. So, the Lab has to consider user equipment and limits. The challenge is figuring out what speed can be achieved with what number of connections without crashing too many routers. LinkSys WRT and Belkin G routers are known problems.