Down with the XMLRPC reply timeout! (Why is it even there??)

I believe the XMLRPC reply timeout is incredibly unintuitive. Perhaps the reason why I think this way is because I'm unsure about how LL has implemented its server. A settable or indefinite timeout would be of great use to me in my current project.

Why are replies limited to 10 seconds after the request is recieved?

Why 10 seconds in the first place? Is it some arbitrary value?

What consequences would increasing thie timeout entail?

If there are really no problems with increasing the timeout value, why not allow us to set this value?

Here's a possible way:
llSetRemoteReplyTimeout(float timeout);

This function will set the time that the Linden XMLRPC server will wait for a llRemoteDataReply from the script in question before sending an error to the server that sent the request.

Linden imput is highly appreciated!
==Chris

Chris - Here's how I look at it. How long should I have to wait before the system lets me know my object isn't responding? Things fail, and 10 seconds is already a long time to wait to determine that. If they implement your llSetRemoteReplyTimeout suggestion, you'll set the timeout longer, and I'll probably set it shorter

"XML-RPM is pretty much screwed in LL's current implementation.. Packets are
being dropped too consistently." - this was in my email from Alondria Lefay who is currently neck deep in perfecting some really kewl stuff for SL. Lindens please look into XML-RPM and make it better.

As Cadroe says, but remember this too:

The 'net isn't a reliable place, so a timeout system is definately required. The static 10 second timeout is a good compromise by LL, as it should be long enough for a piece of work to get done, and the result generated.
The longer a possible timeout period, the greater number of connections are going to have to be kept open, and the greater the XMLRPC server loading will be. Given this system's liable to be intensively computationally battered due to traffic, keeping the load low's a damned good plan.

It could be the script's thread's responsibility to monitor the XML-RPC connection (internally), sending an error instead of a reply if a llRemoteDataReply isnt sent by the developer. If this is true, there is nothing preventing something like the llSetRemoteReplyTimeout function from being implemented. (That's just one way I think LL might have implemented it)

If the XMLRPC server isn't sending data, how is it loaded? Other then having a remote data messageID in its "active" list for a longer period of time, I dont see how changing the timeout can affect performance.

==Chris

You're missing a fundamental concept of TCP.

There is a theoretical limit to the number of open sockets that a single server can maintain on a specific port. There is a realistic limit that's significantly lower than that, and lowered even more by a realistic limit on the total open sockets that the server can maintain on any/all ports.

When your RL server makes a requst of the XML-RPC system, it's like making a phone call. The line (socket) is "busy" until a response comes back and the two participants "hang up."

Since there is a practical limit to the number of lines that can be busy at any given time, it is prudent to place an enforced limit on how long a single "call" is allowed to tie up a line.

**Edited to add that there are infamous personages in SL's history that I would not trust at all to be allowed to control their own timeout settings.