People have been having problems connecting to Second Life™ for as long as I have been using SL, probably longer. As the viewer is shifted to use more HTTP protocol services some are seeing better performance and others worse performance. Whatever the case, more use of HTTP is coming.

HTTP Library

Monty Linden has been working on the communications library used with Second Life. In general we know that work as the HTTP Library. The library is a file that contains all the code to run the HTTP communications channels for the viewer.

Putting all those functions in a single file (I use that idea loosely) gets the code the designation library. The library can be easily updated, used, distributed, and gets all related functions in one place. Eventually most SL Viewer to server communications will be handled through this library.

Monty is saying they have the HTTP Library mostly done and running in QA. Most of his current work is being done on what he calls: Defensive actions.

Defensive actions are usually the error traps and backup systems. In communications a defensive action can be having a fall back service in place for a failure of the primary process. The current viewer has a number of service requests that fall back to UDP protocol communications. Those have to be looked at and converted to HTTP protocol. Just finding them all is a problem.

There is no ETA for the services full rollout. Monty says it is a race with Avatar Baking service. So, that leads me to think February or March for an ETA.

Problems with HTTP

One thing Monty has learned is: some routers supplied to customers by AT&T and German TeleComms fail when used with Second Life. Apparently the cheapest routers fail.

There are also some routers that have a DNS blocking that kicks in when a large number of name lookup requests are sent, which SL can do. The routers essentially lock down for 5 minutes. I suppose it is some misguided effort to stop denial of service attacks. Monty wasn’t naming those problem routers.

I’ll tell you there are a number of cheap routers, like Cisco’s Linksys E4200 (about US$100 for new ones on Amazon, refurbished from Cisco $40, and $29 for used ones on eBay), that are good routers. Unfortunately the router specs normally published really don’t give you a clue whether they will work with Second Life. Search the SL Forum and SLUniverse for any router you are considering purchasing.

Some in Japan are telling us that HTTP doesn’t work so well. Monty looking at the data for connections to Japan can’t see where the problem is all that bad. So, I’m not sure what the story is for Japan.

For now I think resetting the router and seeing if that affects performance is about the only real trouble shooting step for determining if it is a router problem on your end.

Monty has suggested that Third Party Developers consider developing better diagnostics on the viewer side. It isn’t that he doesn’t want to do the work. It is a matter of having the time and when the Lab can get to it.

Communications errors that happen in the first 1 to 2ms of a call are likely local network problems. Errors that happen in 5 to 15ms range are likely ISP errors. Longer time to error or likely on the Lab’s side of things. One can tell better where the handoffs are by running trace routes to see where the local network stops and the Lab’s network picks up. Every thing in between is the ISP’s problem, either yours or the backbone guys.

You can see my Troubleshoot Your #Second Life Connection for more information on figuring out where your connection problems are.