Other than back-end asset storage and lsl generated calls, the interprocess communication in Second Life falls into one of three broad categories. The low latency messaging system over UDP with application state and packet reliability, remote procedure calls over HTTP in either XMLRPC or our own structured data RPC gammer, and a growing collection of representational state transfers of structured data.

The low latency datagram protocol

Nearly every process used in the operation of Second Life communicates using the low latency messaging system. The message system’s primary characteristic is the packet layout which is specified in a template file to facilitate packing extremely compact messages. The message class is represented in 1 to 4 bytes, blocks of related data are specified as a fixed for variable count, and the data fields are typed information blocks of fixed or variable length.
This templetization allows for a fairly easy programmer API for compactly communicating data, but requires that all processes agree on exact encoding of the content in order for it to be decoded. Every time a new feature is added which originates on the client with effects in world, new data which needs to be sent to the client, or information a simulator needs to broadcast to its neighbors, the message template will likely need a change, which will require grid downtime. When an optional viewer update is provided, this is a feature or bug fix which required no template revision.
This scheme is not scaleable in a long-term scenario. Second Life is growing to point where multiple simulator and client versions will need to be running simultaneously on the grid while maintaining communications. Since a new messaging protocol is necessary, no one is eager to release a clear and complete protocol specification.

Remote procedure calls

The first remote procedure call we implemented for Second Life was the login script which accepts an XMLRPC method call from the client and generates a session for the resident. We were pleased with the results of this design since it increased flexibility, testability, and integration with third party languages, tools, and libraries.
The branch of development that was eventually released as 1.9 introduced the concept of structured data, embedded a web-server in the simulators, and started using and XMLRPC implemented in the code as a structured data grammar for remote procedure calls. So far, all agent region changes, instant messages, online notification, and a few other miscellaneous services are implemented as RPC mechanisms. This has worked well, but we are still worried about continued scalability since RPC is reasonable way to request an operation, but not a great way to make a system query since the result cannot be easily cached.
This lack of easy caching has a price. Today, 20% of the central database CPU load is agent online status queries. We are currently replacing that data pipeline with a web based cache that should drastically reduce the load on the database, and once a few more queries are updated, that load will be eliminated.

Representational state transfer of structured data

The agent presence queries and many upcoming features are all based on REST concepts using an XML serialization of structured data. This technique is going to be the focus of new inter-process communication work in Second Life, and will eventually be how all Second Life clients communicate with the grid.

\P/hoenix