Possibilities for harnessing HTTP request/event functionality???

Hi all,

With the advent of HTTP request functionality coming up has anyone considered the following. I haven't looked into it yet but am interested if people already have:

[1] Communications - Possibility of dropping use of CHAT / Email / (LinkMessage) all together and just go to HTTP request/response, complemented with LSLEmail or XML-RPC. That is a single way to do inter-object comms irrespective of whether object is linked, or distance between objects?

[2] Secure Comms - Will secure comms be possible? Would you trust using this approach for items that trigger L$ transfers?

[3] Avoiding loss of events re queue overflow - Currently in LSL it is possible for queues (e.g. incoming link messages, email etc) to go over their limit, noting that there aren't really any facilities in LSL to manage/monitor this queue situation. Would HTTP assist here in a means of pushing all large volume communications through HTTP so that the web-service system can then buffer as many items as necessary?

[4] Offloading load - I assume this will be a useful mechanism for offloading intensive processing out of LSL to the web-server system?

[5] Cheapest serviceside hosting method - What's the cheapest means of subscribing to a web provider service that allows server side script languages to be hosted? That is if one wanted to build some business logic in the outside world to complement an LSL system is PSP hosting say the cheapest, versus Java (requiring someone who could let you host tomcat/java). Anyone looked into this, or aware of the cheapest way out. (e.g. ASP, Java, PSP, PERL etc).

Cheers

1) That depends on the end effect. It really does not replace linked messages, since even with the speediest of backend hosts will you approach the speed of linked messages. It could perhaps have some application for object->object or in particular object->objectS communication. Just be wary regarding the limit on the number of transactions before hitting the thrushold (I believe it is 20/200 seconds currently).

2) Yes and Yes - assuming that the data is send somehow encrypted. Also, make sure there is a reply before actually assuming the transaction has succeeded.

3) This depends again on application. This would not be useful in a single item, since even if you redirected events through the web, there is still the returning data event added, so you would not gain anything. This could be successful if you had a bunch of other objects transmitting to a single server object - the backend could queue and then send the data slower, however this would only work to protect from bursts - if 30 objects are sending per second non-stop, still, you'll never get it caught up.

4) Amen! Probably one of the msot significant reasons to utilize this new functionality. LSL is slow and it's memory is lacking. For anything that would take more than a second to run in LSL shipping to a backend server and then back would be faster.

5) For the most part, any web host will allow for a multitude of backend languages. I doubt for the most part there is much cost differences between utilizing language a vs. language b. The only one I could see is the time involved to create the code for the backend logic and that is rather subjective as far as which one is the easiest/quickest - I would say Perl myself, although I am sure many many would argue.

1) Alondria LeFay the way I am reading your advice/belief, is that a single LSL object with HTTPRequest functionality enabled is only able to send 20 messages per 200 seconds. Is that correct or have I made a mistake in reading your post?


3)In regard to cases of continous multiple requests: when using the new HTTPRequest shouldn't it be possible to have the backend server utilize priority and timestamp variables to ensure timely delivery of messages as well as removing stale dated messages from the queue?

That is what has been found so far. See this thread /290/91/100382/1.html for more info.

I'm new to Second Life and scripting, and when I saw this new feature being added, I was quite excited, as it will open up a lot of possibilities that I have thought of, but the transaction limit could severely hamper the functionality for full interaction with web sites. you can get around it, but it will require a lot of caching or slowing down your users ina friendly way so they don't get annoyed or unexpected results.

Unfortunately, I'm too new to get onto the preview grid, so I can't try it out first hand. Not sure why they have that limit of people born before March 27th?

Hi Russell,

Development grid probably took its user/password list from the main grid on that day.

I too can see problems with the 20/200 rule for any useful purpose that needs reliability.

Maybe a 200/20 rule would be more realistic. Most web sites could withstand that sort of access.

A more complicated way could be to limit transmissions if there was no reply from the target after some sort of timeout. That would need to generate some sort of event to trigger the script into an alternative strategy.

A java socket set up somewhere reliable would be an excellent way to cope with this kind of task. Might be expensive to host reliably, though.

Ed

Ahh ok, yeah that makes sense, I assumed it got it's user base from the live data, but I guess it's completely segregated.

1) To be more precise, it is 20 messages per 200 seconds PER END USER. So if Bob has 10 objects all trying to send four times a second, Bob will have an issue. This makes it extremely difficult to utilize these in a commercial product as someone else's poorly written project could disable yours - I fear the tech support calls already.

2) I haven't mucked around with the timeout delay when utilizing a HTTP Request (basically how long after the request before you won't be able to get the data back in - although RPC'ing it back has possibilities regardless). My main question perhaps is what application has difficulty with the queue constantly filling? It would probably be easier to restructure the workings of the LSL script than to try to utilizing HTTP Request to clear out the event queue.

From my understanding, much of the 20/200 rules is to limit the strain on the sims opposed to preventing a web server from being overloaded. I still contend that since the limit is per user, it in effect makes if difficult if not complete worthless in commercial products to sell since you don't have control or the ability to detect how many other objects the person has that are making requests.

I would simply love to be able to open an arbitrary socket and pass arbitrary data across it. LSL, while it can handle some tasks, is not a particular speedy or powerful language and being able to offload everything except I/O to another server would probably save the sims more work than the socket would take to persist.

From where did you hear the limit was 20 HTTPRequests per 200 seconds?

The HTTP request has its own queue limits and it's also pretty heavily throttled per user per sim, but at least it will return a null key when it's throttled so you can back off your use and provide feedback to the user rather than failing silently.

Re-read the thread! Pay particular attention to the post from Russell Hansen

Ouch, yeah, I forgot about the per user bit and other objects as well. That certainly complicates matters, especially since the general users will not know about this limit, and then buy 2 poorly built items both trying to hammer http and stop working. Let's hope most builders try and handle the throttle responsibly then and at least provide warnings or something and not just leave their owners high and dry.

I thought we were assured by Lindens that only daemons, Jabber repeaters, and user-less scripts would be using HTTP request, because it was too dangerous to send HTTP request/response data between the SL servers and the client.

Why would anyone buy a script with llHTTPRequest in it? I mean, if users are going to be using these scripts, you'd think they could pipe unmetered HTTP requests through the client.

I am obviously missing something, but where did they state this and how is it more dangerous than other communication protocols?

I did see a quote from one of the Lindens saying that httprequest to the SL servers was not permitted, although I didn't see the original source.

I'm not sure on what you are saying though Jarod. Are you suggesting us scripters shouldn't be able to use llHTTPRequest to communicate with the web?

One of my visions which I will be looking at developing is for something such as implementing an LSL versioning and library system by storing and retrieving scripts in a MySql database on my web site, and interfacing to it through an in-game object. I realise this is almost beyond the capabilities of LSL at the moment, but adding the HTTP interface is a step towards that functionality.

This is just one of the web interface functions I'm planning to try when I can get access to the new code, none of which need to talk to the SL servers. The HTTP command I see as a simpler method of doing what can be sort-of accomplished with the current email/XML-RPC protocols anyway, and yes there are ways to abuse either system, which is why they are putting in these limitations, to try and prevent that happening. The balance point becomes where too much security makes the function unusable.

Am I misreading what you are saying?

This thread is the target of my ire. They didn't state that, and I am being facetious, but their answers make about as much sense, imo.

See my response to that thread.

Answer to #5 anyway (which happens to host my weblog and other little things):

http://www.bluehost.com

The other questions I leave alone...

:link:

I second Bluehost...they're great.