Difference between revisions of "Category:LSL XML-RPC"

From Second Life Wiki
Jump to: navigation, search
(Get this started)
 
(Added my text from the old wiki, as I was the sole author of it.)
Line 6: Line 6:
  
 
[http://rpgstats.com/wiki/index.php?title=XMLRPC http://rpgstats.com/wiki/index.php?title=XMLRPC]
 
[http://rpgstats.com/wiki/index.php?title=XMLRPC http://rpgstats.com/wiki/index.php?title=XMLRPC]
 +
 +
=== IMPORTANT IMPLEMENTATION NOTE: ===
 +
 +
The current implementation of XML-RPC only allows ONE request to be queued on the front-end server (xmlrpc.secondlife.com) at a time. Any additional requests to the same data channel overwrite any pending one. This has serious ramifications for the design of XML-RPC communications where the in-world object could receive requests faster than it can respond to them. In addition, the 3-second delay in [[llRemoteDataReply]] exacerbates this problem even more.
 +
 +
The observed issue is this: if you send multiple quick requests to an in-world object via XML-RPC, one which is scripted to perform some processing and then return a response (via llRemoteDataReply), there is a potential for earlier requests to get lost on the front end server (they still should generate [[remote_data]] events, though), and have the response meant for an earlier request end up being passed back to a later one, while the earlier requests will time out back at your external application.
 +
 +
As a result, if you intend to do any serious work with XML-RPC, you will have to design your external client application to manually serialize all requests to each individual RPC channel. That means you have to wait for a response from the previous request before you attempt to send the next one. If you don't care about receiving responses, then this problem is not an issue, as all requests seem to get passed on to the script, regardless of the queueing issue.
 +
 +
Also note that there is NO way to get around the 3-second delay for llRemoteDataReply; you cannot use the multiple-slave-comm-script trick, because XML-RPC channels are *script-specific*, NOT *object-specific*.
 +
 +
For more information, see these forum threads [http://forums.secondlife.com/showthread.php?t=158437 here] and [http://forums.secondlife.com/showthread.php?p=1379244 here].
  
 
==Other Resources==
 
==Other Resources==
 
* [http://www.xmlrpc.com/ XMLRPC.com]
 
* [http://www.xmlrpc.com/ XMLRPC.com]
 
* [http://scripts.incutio.com/xmlrpc/ Incutio's XML-RPC PHP library]
 
* [http://scripts.incutio.com/xmlrpc/ Incutio's XML-RPC PHP library]

Revision as of 13:25, 15 May 2007

XML-RPC is a standard for sending Procedure Calls (e.g. function calls) to Remote systems. It sends XML data over HTTP that remote system then handles.

LSL receives XML-RPC requests and passes them to the prim specified. It may not establish this connect, but it may reply and keep two-way communication with that server. These responses seem to be able to transport a largest amount of data out of Second Life (vs. Email and HTTP Requests).

Due to potential copyright issues the following article will be linked rather than imitated, it should get you well on your way:

http://rpgstats.com/wiki/index.php?title=XMLRPC

IMPORTANT IMPLEMENTATION NOTE:

The current implementation of XML-RPC only allows ONE request to be queued on the front-end server (xmlrpc.secondlife.com) at a time. Any additional requests to the same data channel overwrite any pending one. This has serious ramifications for the design of XML-RPC communications where the in-world object could receive requests faster than it can respond to them. In addition, the 3-second delay in llRemoteDataReply exacerbates this problem even more.

The observed issue is this: if you send multiple quick requests to an in-world object via XML-RPC, one which is scripted to perform some processing and then return a response (via llRemoteDataReply), there is a potential for earlier requests to get lost on the front end server (they still should generate remote_data events, though), and have the response meant for an earlier request end up being passed back to a later one, while the earlier requests will time out back at your external application.

As a result, if you intend to do any serious work with XML-RPC, you will have to design your external client application to manually serialize all requests to each individual RPC channel. That means you have to wait for a response from the previous request before you attempt to send the next one. If you don't care about receiving responses, then this problem is not an issue, as all requests seem to get passed on to the script, regardless of the queueing issue.

Also note that there is NO way to get around the 3-second delay for llRemoteDataReply; you cannot use the multiple-slave-comm-script trick, because XML-RPC channels are *script-specific*, NOT *object-specific*.

For more information, see these forum threads here and here.

Other Resources

Subcategories

This category has the following 2 subcategories, out of 2 total.