llHTTPRequest...what are the possibilities?

What can we use this for? I'm just curious...

Me too, I don't know what it's capable of but I heard some Resis very excited about it on the Preview Grid, so great things I hope.

it seems this is the famed 'outbound communications' option, other than email.
It basically allows a page request or a form post, as a browser can.

It can be used for:
- faster communication initiation. Instead of an email to trigger a communication session with an external server (clunky), a simple outbound request can now trigger inbound xml-rpc requests, allowing for quick and easy bidirectional communication.
- Info requests. Also from sites which aren't 'built for SL'. Think info scraping of existing websites etc.

What does this mean:
- much simpler webshop comms.
- easier secure communication (public key exchange)
- scraping of news/quotes/weather/blogs/l$ rates/search results etc. from websites.
- fast bidirectional communication for: navigation tools, name2key functions, delivery requests from 'personal vendors', infohub systems, fast external processing for in world games, intelligent robots etc.

I probably only touched the surface here.

Oh... and massive (D)DOS attacks from the grid to external servers. But i assume LL probably throttled/prohibited this

Thank you Damani!

On the docs on the script wiki (that Babbage posted), it says they are throttled by user.

Ah, well, that's crystal clear then.


(Edit: it said throttled per owner, which i get. Basically only a certain amount per object owner, per timeframe, are allowed, independent of number of calls, scripts or objects in world)

Hmm, the problem with limiting per owner is this.

Say I want to attack example.com I could create a cool object, and hide in it my attack script. I then hand it out for free and make it copyable. It spreads from person to person and soon we have a huge hit against example.com

How can one company, Linden Labs, cause a distributed denial of service attack? At worst example.com might have to block connections from the SL server farm and report the problem, at which point LL can take a look at what script(s) are making outbound connections to example.com and take the appropriate actions.

I made no claim that it was distributed, though Im sure that LL has quite a cunk of bandwidth that you could throw around.

Anyone know what the throatled rate is? It would be nice to allow "whitelisted" servers that can be proved to be owned by a person to be able to break this rate.

I did some quick & dirty tests on SIVA to test how many requests I can make (and how fast) before my requests get blocked. Here are the results:

20 requests in 2.715820 seconds. (burst)
20 requests in 23.011963 seconds. (every 1 second)
20 requests in 43.286621 seconds. (every 2 seconds)
20 requests in 64.187012 seconds. (every 3 seconds)
20 requests in 83.488770 seconds. (every 4 seconds)
20 requests in 103.383789 seconds. (every 5 seconds)
20 requests in 123.271973 seconds. (every 6 seconds)
20 requests in 143.390625 seconds. (every 7 seconds)
20 requests in 163.693848 seconds. (every 8 seconds)
20 requests in 183.536133 seconds. (every 9 seconds)

Which means, no matter if you send 20 requests as fast as you can, or send a request every 9 seconds, you will get blocked when trying to send the 21st request.

When I tried sending a request once every 10 seconds, I didn't get blocked at all, even after approx. 10 minutes, so in my experience, you can send up to 20 requests in 200 seconds... go faster and you'll get blocked.

I couldn't figure out for how long the subsequent requests are blocked, but it seems that failed requests also prolong your blocked time, if done too frequently - meaning, if you'll try to send a request every 5 seconds just to check if you're still blocked, you might not get unblocked at all. When I tried checking every 30 seconds, I usually got unblocked after 300 - 360 seconds.

Hope this helps, did anyone do any similar tests? What did you find out?

This sounds very promising, but perhaps a bit more information about the throttling could be useful? I mean, say someone makes a vendor that uses this capability, and then distributes this vendor, making sure it only sends data every 10th second, by storing data, and then sending it as one request (since there's no mentioning of a limitation in the length of "Body".

If this vendor becomes popular and used by several people, like the SLBoutique vendors, then if the throttling is solely based on the owner of the script, then it won't be long until a lot of vendors starts spewing out errors into the debug window.

I've so far seen two Lindens express themselves about these functions, yet neither of them seem to really know anything about it (I assume their areas are somewhat different), but would it perhaps be possible to get a comment from one of the implementors? Would be really nice. Well that, or just a more thorough description in the LSL wiki.

AngelOD, if I understand correctly, throttling is implemented per object owner (not creator, as you might have misunderstood) and per region, which means your requests can be blocked in one region and not in the other.

That's all good and fine, but it's still just speculation (and some testing). It would still be nice to have some facts from one of the involved developers, and even if it's script owner (I didn't misunderstand that one, it was just a brainfart, as I thought of the owner remaining the same when the script was inside a non-modifiable object, but that's not the case, so yeah.. Heh..), it's still likely to cause problems for people who have more than one vendor, if these are of the same type. Like, say, one of the larger shops. I can think of things like clothes/AV shops that might get a problem with this.

Agreed.


I'm aware the current throttling scheme is preview only, and things might change, but yes - I do see a huge problem also, with the way throttling is done at the moment. Because its owner (as opposed to script) based, it means one poorly written object might break all my other objects that use llHTTPRequest (and thats not just speculation ). While I do understand why throttling is owner based, it might need a bit of fine-tuning. Simply put, If I make an object, and work hard to make sure its working correctly at all times, I don't want other objects interfering with it (making it unable to send requests for long periods of time, or deliberately crippling its operation). How will I explain to a newbie that my super cool & overpriced gadget doesn't work, because his necklasse is talking to google.com every 5 seconds?

My point exactly! I understand the need for throttling, since there are always people who will try to ruin it for the rest, but like you, I think there's got to be a better way. I haven't given much thought to how I would do it, but delaying the scripts (as with other functions) would be a given. It wouldn't prevent abuse (just as it doesn't with other functions, like llEmail), but that's where sensible logging features could come in. Having it log all requests to domains, perhaps including a small excerpt of the request, so an external logparser could run through it, and notify someone of a possible abuse.

Of course, it's far easier said than done, and the logging might affect the system negatively, which wouldn't be good, so I dunno.. It's a bit of a fickle.

Nooooooooooooo!!!!! Please, no delay!! A delay just means I have to make multiple scripts, each taking its 16k and bogging down the sim even more. Delays mean unneeded complexity in scripts and worse performance for the sim. I *love* it that llHTTPRequest has no delay.

Uh-huh.. Riiight.. How would you solve the aforementioned throttle-problem then, if not by delay? The current method is likely to cause trouble for the reasons also stated in earlier posts..

As I suggested in the main thread for this feature. I think the best solution would maybe to replace the 'blocking' with an exponential delay. Basically, if you play nice then the delay will be nothing at all or neglibable (a small fraction of a second), but if your script is churning out requests, then a the delay after each request grows rapidly.

So if you make 20 requests in one second, then do nothing for 9 seconds, the throttle won't be hit so no delay is incurred.
If you make a 21st request, a delay of 0.1 second is incurred on all subsequent requests to force the script to slow-down, if it's still churning them out then it starts getting higher until the script(s) are FORCED to make no more than the throttled number of requests, as they'll become so slow that they simply can't send requests fast enough until the delay starts to drop (if the number of requests slows down).

So in essence, instead of blocking the requests, it introduces script lag/delays, but ONLY if your requests are hitting the throttle limit.

Having the throttle dependant on owner is a good idea, in my opinion, because it puts the burden on the user who has all kinds of gizmos all running at the same time. This is better than the way things work now, where I can walk into a club with fantastic prim hair and a complex torus dress and detectors and HUDs and bling out the wazoo (figuratively speaking) and it affects everyone there.

Haravikk's progressive delay sounds like it might be a good compromise.

There's been some suggestions that people will use llHTTPRequest for a vendor that sends a notification of each sale. I think that's a bad idea, and I don't plan to change my vendor scripts that currently use email for this. The great thing about email is that my host can be down for any reason, but that email is still safely stored on the email server until my site is back up. llHTTPRequest should certainly replace many of the email-to-xmlrpc and email-to-email designs we have now, where the SL object needs a response, but it's my view that fire-and-forget designs should still use email.

Heh, nevermind about the previous post, I see what you are saying.

But it'll be better for some 'realtime' applications such as plotting positions, ordering airstrikes, keeping a running Shoot To Kill and Don't Maim Too Much lists for all my security systems across the grid.

Well, I'm still very new to SL (first post on SL forums :]), so may be a little off target, but my immediate thought when I saw this feature was "In game version of RL web shop". People browing throuhg a web shop catalogue may certainly be sending many requests in a short period. Some form on script caching to send chunks of data may help alleviate the problem, but with a low rate of 20 request in 200 seconds, it certainly seems to limit this functionality.

The idea of exponential delays sounds like a better idea to me as well.