A big change you’ll barely notice

The next release will contain a major piece of new functionality that, if we’ve done it right, you won’t even notice. I can hear you all exclaiming “What?!?!”, and warming up those comment forms… But hear me out.

We’ve just completed and passed the first phase of the “sim-caps” project. As Cory alluded to in his Town Hall, this project enables the simulator and viewer to communicate using a collection of standard technologies: TCP, HTTP, SSL/TLS and XML. These offer a better match of performance characteristics for much of the viewer communications, and benefit from the many years of development these technologies have had.

So why won’t you notice? Because for this release we took an extreme view of writing software in a way that has very low risk to the grid:

• Only a small number of operations will use the new system at first
• The existing messaging code for those operations has been left in place
• The grid can be switched, on the fly, per operation, between using the old messaging system and the new.

This last technique is notable: It represents an engineering approach to designing with the goal of not taking the grid down. We will be building more new functionality with this kind of “live fallback”. And how do we know the fallback works? The “sim-caps” code has been deployed for about a month – we’ve just been using the live configuration to keep it turned off!

While this change is small, it is the first step in the very large set of changes Cory talked about yesterday. The next steps will involve greater and greater functionality and you’ll begin to see the benefits in how things function. The end of this path is a day when we can update the grid, viewers and simulators, in pieces, without ever taking it down.

If you’ve read this far, you must have a real tech. fetish, so let me indulge you a bit more!

The “caps” in “sim-caps” stands for capabilities. This is a well known design pattern whose biggest success has been web cookies. Now before you all jump on that, realize that cookies, properly implemented, are what make the internet go ’round. It is how every major site with accounts keeps you logged in. We’ve taken much care in our capability design and use strong security (SSL/TLS). And unlike cookies which are “all-or-nothing”, our capabilities are for small pieces of functionality, valid for short periods of time. If one is compromised, it won’t compromise the whole system or even a large part of it or even your whole account. (See these entries in Wikipedia: Capabilities — HTTP Cookie)

The messages themselves are built upon LLSD, our own developed technology for encoding structured data. This is, in turn, serialized to XML and sent over the wire. While this does increase the number of bytes it takes to encode messages, it offers a degree of forward and backward compatibility we don’t currently have with the current message system. (Which is why you all have to download new viewers every time we update.) Messages where this overhead is significant will still use the existing system. Fortunately, those messages are well established and haven’t changed in ages.

The first set of operations that will use the new messaging system will be: teleport, region crossing, some map data, and asset uploads. This will almost certainly change the timing of teleport and region crossing – in some cases slower, in others faster.

If you like peeking under the hood (don’t mind the grease), then look at the Second Life log file. Today, you can find this line:

2006-12-21T04:39:08Z INFO: BaseCapabilitiesComplete::error 499: STATUS_EXPIRED

Which shows that the viewer is trying to get the capabilities, but that right now, the server isn’t giving out any. Hence, all functions are running over the old message system.

When you open the map, the log will show:

2006-12-21T05:40:36Z INFO: LLWorldMap::sendMapLayerRequest via message system
2006-12-21T05:40:36Z INFO: LLWorldMap::processMapLayerReply from message system
2006-12-21T05:40:37Z INFO: LLWorldMap::processMapLayerReply from message system


This shows map layer data (which is a small portion of the map data) being requested via the existing message system. Notice that it takes multiple replies to get the data back, as the data doesn’t all fit in a single UDP packet. In the future you’ll see “via capabilities” in the request, and only one reply, which will say “from capabilities”. This is because over HTTP we can deliver the whole response in one go. That in itself is a big win for many of our messages.

Hope you’ve enjoyed this rather technical romp. I’m spearheading the whole messaging infrastructure project and will try to keep you informed as we hit major milestones like this…. even if you’ll barely notice!