Difference between revisions of "Transfer Manager"
Rob Linden (talk | contribs) (+protocol nav) |
Poppy Linden (talk | contribs) |
||
(4 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
{{ | {{ViewerArchNav}} | ||
The LLTransferManager class is a throttled data transfer system which is used primarily by the [[Asset System]] to fetch assets from Second Life. A transfer manager client makes a new instance of a class derived from LLTransferSourceParams, a new instance of a class derived from LLTransferTargetParams, and issues the request with a [[TransferRequest]] message. | The LLTransferManager class is a throttled data transfer system which is used primarily by the [[Asset System]] to fetch assets from Second Life. A transfer manager client makes a new instance of a class derived from LLTransferSourceParams, a new instance of a class derived from LLTransferTargetParams, and issues the request with a [[TransferRequest]] message. The source parameters are thrown away, and the client process creates an appropriate LLTransferTarget instance which copies the target parameters. | ||
When the [[TransferRequest]] comes in, the transfer id is used as a primary key in the server to index the transfers. Since duplicates are discarded and the key should be unguessable, it should be safe to key on a client generated uuid in this case. Colluding clients generating identical keys will get one successful request and one client with a likely memory leak. | |||
Requests for file sources will fail. Requests for assets are constrained to assets which the viewer is allowed to request via asset id. Asset requests are never prioritized in the asset queue regardless of client specified priority. Requests for inventory items are constrained to the assets in agent or task inventory according to the client source parameters on initialization. | |||
[[ | Textures are moved the through the [[Texture Pipeline]] -- not the transfer manager. | ||
[[TransferPacket]] | When the server has collected the requested data, it sends a [[TransferInfo]] message to the viewer, followed by as many [[TransferPacket]] messages as necessary to transmit all data. If a [[TransferPacket]] is received before the [[TransferInfo]], or out of order, the data will be stored and replayed once the information shows up or the preceding packets arrive. If too many [[TransferPacket]] are queued for delayed delivery, the transfer will be aborted. | ||
[[TransferAbort]] | The [[TransferAbort]] message can be sent from either side to end a transfer. The message is sent in response to incorrect accounting information, reliable packet delivery failure, or too many delayed packets. | ||
[[Category:Assets]] |
Latest revision as of 15:30, 26 May 2010
The LLTransferManager class is a throttled data transfer system which is used primarily by the Asset System to fetch assets from Second Life. A transfer manager client makes a new instance of a class derived from LLTransferSourceParams, a new instance of a class derived from LLTransferTargetParams, and issues the request with a TransferRequest message. The source parameters are thrown away, and the client process creates an appropriate LLTransferTarget instance which copies the target parameters.
When the TransferRequest comes in, the transfer id is used as a primary key in the server to index the transfers. Since duplicates are discarded and the key should be unguessable, it should be safe to key on a client generated uuid in this case. Colluding clients generating identical keys will get one successful request and one client with a likely memory leak.
Requests for file sources will fail. Requests for assets are constrained to assets which the viewer is allowed to request via asset id. Asset requests are never prioritized in the asset queue regardless of client specified priority. Requests for inventory items are constrained to the assets in agent or task inventory according to the client source parameters on initialization.
Textures are moved the through the Texture Pipeline -- not the transfer manager.
When the server has collected the requested data, it sends a TransferInfo message to the viewer, followed by as many TransferPacket messages as necessary to transmit all data. If a TransferPacket is received before the TransferInfo, or out of order, the data will be stored and replayed once the information shows up or the preceding packets arrive. If too many TransferPacket are queued for delayed delivery, the transfer will be aborted.
The TransferAbort message can be sent from either side to end a transfer. The message is sent in response to incorrect accounting information, reliable packet delivery failure, or too many delayed packets.