llHTTPRequest "hanging on the telephone": sim ecology?

Hi folks,

I've been considering recently modifying an existing web-based system to use the delayed response (aka, "hanging on the telephone" strategy for HTTP requests.

Basically, the SL object makes a request to a web server to see if a particular event has happened or not. If it has, the server tells it so. However, if it has not, the server _willfully delays responding to the HTTP request_, thus holding the connection open, until either the event does happen or the request times out (after 60 seconds, according to what I've read here). This ensures that the object can be notified immediately when the event happens without having to hammer the HTTP server to death by polling it.

Just a few questions about this though:

1) Is this harmful to sim ecology? I've seen, live in-world, that there is a SECOND throttle on HTTP requests which applies at the sim level. (It gives the error "Too many HTTP requests from this region", as opposed to "Too many HTTP requests too fast", and it doesn't matter who owns the objects.) I'm guessing there's a limited number of network ports available for the SL machines to make HTTP requests from, and keeping them locked open may hog these resources.

2) Does the PHP script on the server also have to be written to time out after 60 seconds, or will the server-side PHP engine cleanly stop it if/when the client breaks the connection? Can the PHP script somehow detect that the SL client timed out?

assuming KEEP_ALIVE is being set for the request (and I didn't think it was) you probably don't need to timeout the php, just kill it on disconnect

Assuming the above I can't imagine it'd make a HUGE difference to hold the connection, as it'd be no different than a slow/ignored normal http request... unless of course it's being heavily used. just guessing there

if KEEP_ALIVE isn't being set for the connection, you'll have to manually timeout the php request and possibly manually keep it waiting

I would think it'd be set up as the latter, to cut down on network resources but who knows

It would be helpful to find out what kind of «event» you're waiting to happen on the Webserver.

You could do it a little more complicated, but this would cause less lag - on both sides, SL and the Webserver.

- Send the HTTP-Request from SL without waiting for an answer.

- set the Object to listen to an RPC-Request from your server

- Make the PHP-Script send out a RPC-Reqeust to the Object in world when the «event»*happened.

That way, no matter how long the «event» takes to happen, your object will always receive it. When you choose to keep the connection alive, you might get in trouble with your provider IF he allows you to do so. And you might as well consider that not all providers allow 60 seconds of script execution time - mine allows only 30 secs, so if your script takes longer than that to execute, you might get a failure anyway...

HTH

That's actually the way I was doing it before, but SL's XMLRPC server has become too unreliable to continue using it.

This is the idea behind http://w-hat.com/muginet and I have not seen any ill effects from it. I'm curious how many requests it takes to trigger the sim-level throttle though, I've tested with a few thousand and never ran into it.

It is MUCH rougher on the http server. Normal web servers are not designed to have idle connections hanging around, and you will quickly run into denial-of-service conditions with a typical Apache setup and any significant number of connections. It is an especially bad idea on shared hosting setups, where Apache and PHP have every stupid whiz-bang gadget anyone could ever want, and each thread takes 50+mb of memory.