XML-RPC communication is unstable

Hi,
did anybody notice that last week xml-rpc became too much unstable? i think this is happened after rolling restart for 1.27.2 server.
I'm noticing that some xml-rpc calls do not reach destinate in SL, but after few minutes when repeating same call it reaches destination. Other case is when you have to re-open xml-rpc channel too often because previous crashed quickly.

XML-RPC has not been trustworthy for a couple of years now.

With the rollout of http-in, the future of XML-RPC is very dark. I would expect them to shut it off once its usage drops below a certain threshold. It is likely that the service level will degrade significantly before that time as well., with regular outages and slow responses.

As such, I would make with the updating of any product/service which depends on it, and do so ASAP.

yep, HTTP-IN is the new Black.

It's unwise to rely on XML-RPC (or even HTTP-IN really) anyway, you're better to have your system work by requesting a page with llHTTPRequest(), and poll regularly. You can then add HTTP-IN/XML-RPC/E-mail handlers which allow you to trigger a poll on demand, so you don't have to poll too frequently to get decent performance.

This way your system is a lot more robust overall, and if you want you can throw some actual data into the HTTP-IN and e-mail requests so that they can be dealt with immediately, if your system can handle that at least.

I disagree with respect to HTTP-In. It has proven fast, reliable, and quite flexible enough for most applications so far, at least as far as my experience goes and what I have heard from others. It is just the other side of the llHTTPRequest() coin, and llHTTPRequest() is very dependable. The only issue is the transient nature of the generated URL. If you can design around that--and it is pretty easy to do so for most applications--there's no reason I know of not to go with it. In fact, I have a system setup to go both ways: the in-world objects make frequent use of llHTTPRequest(), and pass their URLs each time they use it to keep the URL fresh. The web server uses the latest URL and handles the exception where it is unreachable just in case.

XML-RPC, on the other hand, has not only been extremely unreliable, but was flawed design-wise from the beginning. And e-mail in general is not meant to be either reliable or timely. So I agree with you on those, but not on HTTP-In.

Simple reason why you can't rely on HTTP-IN either; stuff fails. Sure it's very fast and reliable, it's absolutely brilliant in fact.

But it's entirely possible that at some point in time one or more of your HTTP-IN messages will not make it to your object in-world, and you need to be able to cope with that, as (other than the obvious lack of a message) it could leave crucial state values out-of-sync between your object and the server, or any number of other nasty things.

For this reason you cannot expect HTTP-IN to always work this well, or even to work at all on some occasions, and build your system so that it can still function in these cases. As I say, you can do this by having your web-script try HTTP-IN first, if it fails then it can try XML-RPC, or send an e-mail, all with a chance of getting to your object. But if the object is also able to poll its data via llHTTPRequest, then at least if it doesn't get the inbound message at all, then it can still perform its task.

Hmm. Good point. Well, then I suggest you figure out how to do it without a network, because networks stink and always fail at SOME point. If you think ANY protocol is reliable 100% of the time, I've got a bridge to sell you. Truth is, you're just going to have to design your overall system to handle such errors somehow.

The difference is that XML-RPC fails often, and llEmail is laggy often. Even above and beyond issues like the sim the server is in lagging/crashed, or having your server object/script crash.

HTTP-In solves the failure/lag problems inherent in the other two, in terms of the medium, so you are left with the outages common to ANY client/server implementation in SL, even chat-based ones.

If anyone is designing C/S implementations which are not fault-tolerant, they likely are going to be frustrated to the point of giving up, and rightly so. That kind of haphazard design is naive.

Which is exactly the kind of thing I'm trying to highlight. It's amazing how many scripts just blindly rely on XML-RPC, and I fully expect the same to happen with HTTP-IN (probably a far whack of the scripts already out there using it don't do so properly).

Besides which, there are other conceivable cases than simple outages. For example, what if some kind of security concern arises and to protect the grid LL temporarily disable HTTP-IN? There's nothing stopping them from doing this if they have to, and if HTTP-OUT continues to work in these cases then you're going to want your scripts to continue functioning.

I am not sure what the point of your first post is, then. I think what you are saying has nothing to do specifically with HTTP-In, but client/server programming in general. There are times when the client/server link breaks or is unavailable. That doesn't really even speak to the fact that HTTP-In is a much more robust (and a longer-term solution) than XML-RPC or llEmail, which was the point in previous posts that you seem to have been responding to.

I would MUCH rather "rely" on HTTP-In, with the necessary caveats for graceful exception handling, than XML-RPC, at this point.

As for using llHTTPRequest and polling, that is a very non-scalable solution to use wholesale. Maybe as a fallback or intermittent "exception" case, but not as a mainstream solution.

I think that depends a great deal on the application. When there are going to be a great number of objects/scripts that act as clients to the web server, and it is infeasible to keep track of them, polling with llHTTPRequest() can be a good solution. When there are just a few in-world objects/scripts that will benefit from the web-initiated messaging, HTTP-In makes more sense. And there are plenty of cases when a hybrid solution may be optimal too.

Actually, that's the non-scalable part. When you have objects which can poll the webserver every few seconds, and then potentially have thousands to tens of thousands of said objects, you're gonna have to have a pretty beefy webserver to handle the load. In that case, polling isn't such a good idea.

The main problem with XML-RPC, besides it being an overloaded bottleneck that is hugely unreliable a lot of the time, is that you can only have one pending request per object at a time. That's all it keeps track of.

I'm aware that it is all about the application, but it doesn't change the fact that polling is not a scalable solution to use as a primary mode of communication, unless the application uses it very infrequently.