Revision as of 15:05, 3 October 2008

Asset Server Proposal

Motivation

Many virtual worlds are being developed independently with a wide variety of different architectures and protocols. However, one common component across these worlds is an asset service. An asset service is the means of storing and serving static content that populates the world; anything from textures and 3D meshes to clothing definitions can be stored. Most implementations, including Second Life® and its open source derivatives, have opaque asset hosting that is a part of the world itself.

The opaque asset hosting model has a choke point at the simulator level. Asset downloads make up the bulk of virtual world bandwidth requirements, and in the current Second Life model all assets must be proxied through the simulator.

The goal of this project is to design a common protocol for hosting and retrieving assets in virtual worlds with scalability and a wide set of use cases in mind. In the proposed architecture, control of assets is moved from grid owners to content owners to allow cross-world assets with content authorization management. Protocol enhancements could include better support for content rights, asset hosting as an independent service, asset migration between worlds, and scalable performance by allowing centralized servers to be removed from the equation.

The short-term goals are to consolidate on a common metadata format with core features for version one, and build a reference asset service that plugs into the OpenSim UGAIM model.

Asset Hosting as An Independent Service

The current model of asset hosting approaches trust and permissions from the viewpoint of a grid. Users authenticate with a grid login service, upload assets to grid asset storage, and set permissions that apply to other users of that grid. By moving authorization to the asset storage, an asset service no longer needs to be tied to a specific grid and can serve anyone who is properly authenticated. This opens up the possibility of web service access to assets or asset metadata, or other use cases that do not directly involve logging in to a virtual world.

Leveraging Existing Infrastructure

With asset serving separated from grid-specific code, the solution looks similar to existing solutions. Proven infrastructure for asset lookups, authentication, serving metadata, and content distribution can be used as building blocks.

Scalability

The difficult research in scalable content distribution has already been done and implemented across the web in various different implementations. The goal is to reuse that existing knowledge for virtual world assets, adding optional features such as identity-based permission levels or new caching strategies.

Terminology

• Capability: A session cookie that is temporarily stored on a server and sent to a client that proves authentication or grants access to a part of a system.
• Asset ID: A 128-bit identifier for content in a virtual world. These identifiers may or may not follow RFC 4122; the specific implementation is out of scope of the asset service. Asset IDs only have context in the grid they were created in.
• Grid: For the purposes of this document, a grid is defined as the set of services where a particular Asset ID has contextual meaning.

Protocol Overview

1. The end user retrieves a capability to connect to an asset service. This can be returned by directly connecting to an asset service and supplying OpenID credentials, or an out of band method such as logging into a virtual world grid server.
2. The end user does a GET operation, supplying the credentials from step 1, and requests the metadata for an asset ID.
3. The asset service performs a lookup step which resolves the ID to metadata which includes the location of the content, a list of supported REST operations on the content, and additional information, such as the dimensions of a texture.
4. The end user has information on different valid operations on the asset, and in the most common scenario will choose to use the fetch operation to download the asset.

All user-facing services must be available over standard HTTP 1.1, and must adopt at least one common metadata format.

Asset Metadata Request

An end user must discover the asset service through some means. The specific means of discovery is out of scope of this document but could for example be built into a client application, provided during grid login, or published on a webpage. To request asset metadata, an HTTP 1.1 GET is made to the asset service with the asset ID and metadata operation specified. For example, a request might look like:

GET /89556747-24cb-43ed-920b-47caed15465f/metadata HTTP/1.1
Host: assets.virtualworld.com
Date: Mon, 22 Sep  2008 12:00:00 GMT
Authorization: OpenGrid ce9a6995-a737-4206-bae8-910cae310e94

Authentication

Access to the asset service methods is controlled with a capability token, a UUID. This UUID is a non-guessable, temporary token assigned to an end user at the end of a successful authentication process. This token could be assigned by an authentication through a virtual world login server, or through a direct login to the asset service itself using OpenID. Temporary tokens must only be given out to authenticated end users, and should be expired similar to HTTP cookies.

If the asset service supports direct logins, it should respond to unauthorized requests with a response that includes an OpenID Endpoint URL. [METADATA TODO]

Once an authenticated request for an asset has been made, the asset service determines if the authenticated user has authorization for the requested content. If a request is unauthorized, a 403 Forbidden response must be sent back to the end user, optionally including an OpenID Endpoint URL so the user can choose to authenticate with another identity.

Lookup

Once a request has been authorized, a lookup is performed. This could be as simple as a map<UUID,metadata> or a scalable solution such as a distributed hash table. The lookup resolves the asset metadata and asset location, and together with the authorization can determine the list of supported actions that are returned in metadata.

Metadata

The metadata provides information on supported methods for the resource and information about the resource itself (such as the size, dimensions, and average color of a texture). One of the goals of this research is to work with the community to develop a common metadata format for requests and responses. [METADATA TODO]

Examples

The following example shows a request for the lowest quality layer of a texture asset.

GET /535f9839-64a9-4146-9e14-a2e2e7896cf1/metadata HTTP/1.1
Host: assets.virtualworld.com
Date Mon, 22 Sep  2008 12:00:00 GM
Authorization: OpenGrid ce9a6995-a737-4206-bae8-910cae310e944

HTTP 1.1 200 OK
Date: Mon, 22 Sep  2008 12:00:00 GMT
Last-Modified: Sun, 1 Jan 2006 12:00:00 GMT
Content-Type: application/xml
Content-Length: 223

<?xml version="1.0" encoding="UTF-8"?><properties><layer value="0" start="0" end="334"><layer value="1" start="334" end="98281"><width value="512"/><height value="256"/></properties><methods><method value="data"/></methods>

GET /89556747-24cb-43ed-920b-47caed15465f/data HTTP/1.1
Host: assets.virtualworld.com
Date: Mon, 22 Sep  2008 12:00:00 GMT
Authorization: OpenGrid ce9a6995-a737-4206-bae8-910cae310e94
Range: bytes=0-334

HTTP 1.1 200 OK
Date: Mon, 22 Sep  2008 12:00:00 GMT
Last-Modified: Sun, 1 Jan 2006 12:00:00 GMT
Content-Type: image/jp2
Content-Length: 334

...