push to client in xmlrpc

xmlrpc looks like a stateless connection from client to server for each xmlrpc message/response pair? I assume this means theres no way of directly pushing data from the server to the client but just want to confirm?

Azelda

No, there isn't. The only two workarounds (that I'm aware of) are to either use email to initiate the sequence from in-world, or have the off-world "client" periodically poll the server to see if the in-world script has any data waiting to be sent back.

Hmmm, it's sortof like having the subway ticket machines on the wrong side of the barriers...

Azelda

Many people have been complaining about it since XML-RPC was first implemented. The client-server model that exists forces you to write your "server" in LSL as an in-world object/script, and your out-of-world system is the "client." A situation that, frankly, boggles the mind (mine, anyway.)

What I heard from lindenlabs is that they were affraid for DDOS attacks... ofcourse they have a a point there.. but what about the email-command? you can also make an email-dos if you want, but they didn't disable that feature either...
so if you ask me, just enable the outbound XMLRPC

AFAIK Azelda doesn't even need the outbound XML-RPC (that can be initiated from outside), even if you have to get the channel key to the outside "client" by other means (llEmail), having a way to push data to it once the connection is established would be more than enough. I don't see how that could lead to DOS attacks.

To me, its such a dissapointment that it was implemented in this manner. The principal selling point of this feature was the ability to create HS interaction with objects and external servers. At this point in time, this model is so ineffecient in how it must be implemented that I have personally dismissed it as "good intention but nearly useless".

I have attempted a few projects with it, and it brings an entire level of complexity in that to acheive anything that is infact operated and simulated by a remote server. Objects require constant polling which generates unneeded traffic for when a LSL object is idle (between user interactions). This is a computing and network performance cost to both LL and myself. CPU cycles and bits on the line equated to cash, which I spend way too much of already Furthermore, to properly implement this in an automated way, Email must be used to start the interaction. This brings a new level of complexity to the project.

As of the current moment, the basic use for XMLRPC is to allow you to retreive information from SL, and thats about it. While this in itself may be usefull, it does not really allow the level of "interactivity" that we were initially led to beleive in.

As for the arguement of "DoS" attacks, there are ways to curb this. One must just be creative. While it may be next to impossible to eliminate, it can be curbed. IE: a user-definable list of 1-3 servers (no URLs, just servers) may be queried (even just 1), impose bandwidth and SYN throttling (a common feature on higher end firewalls). While these may impose more of a load both in manhours and system resources, these would effectively allow LL to be able to know with a higher level of confidence at DoS attacks originating inworld. Furthermore, specific additions to the TOS could be added to cover this and us as developers could even be given caveats in the Script Docos covering this subject.

If we had the flip of the current XMLRPC system in place, it would be ideal. Have the LSL object deliver data to remote servers, have the LSL object be able to query through a straight forward means data FROM a remote server.

Just my two cents. Good luck Azelda. If theres any help I can provide you with your issue, feel free to IM me. Just a word of warning, it can be done, but its not pretty. Polling sux. :/

Let me demonstrate how such a DoS attack could conceivable take place. Take 1 XMLRPC script, quering a single webserver. Add a dash of a self-duplicating fun. If you have the extra time and wish to really make it enjoyable, add a random movement script accross sims to give it that nice little touch.

In short, have your payload in a self-duplicating prim, press go. Et voila, instant website traffic. Overtime, the XMLRPC requests (being HTTP based) will overcome the poor webserver(s) on the other end. And depending on how much work you do, you can employ nearly the entire mainland as your launcher with each supporting dozens of requestors at once.

> Let me demonstrate how such a DoS attack could conceivable take place. Take 1 XMLRPC script, quering a single webserver. Add a dash of a self-duplicating fun. If you have the extra time and wish to really make it enjoyable, add a random movement script accross sims to give it that nice little touch.

Yeah, but you're crashing your own webserver, and it's all traceable back to you, since you made the initial outbound connection from your webserver. Your hosting will terminate your account, end of story.

Azelda

Wait, I don't do XML-RPC anything yet, but wouldn't it be possible to simply "query" www.google.com or something? That'd be "traffic" too, just like ping-based DoSes.

No, not the way xml-rpc works at the moment. But thats one of the reasons LL hasn't offered us two-way xml-rpc connections - before they do, they need a way to make sure you can't just open a connection to every http server out there and bring it to its knees.

What I spoke of is if LL made it so LSL objects could be a XMLRPC clients. This could be theoretically any HTTP server. Therefore, SL could be used as a platform to initiate a "DoS" attack on a specific webserver. Et voila, now LL has to deal with policing of their userbase more than they already are.

Yeah, but MSo, I and others are suggesting that once youve created a channel to SL with your Sl object as a server, then the object can connect back to you using you as the server.

Azelda

Stop trying to solve social problems with technology.
In my world, there's this thing called the legal system, you know.
This is precisely what it was made for.
If LL made cars, they would all be technologically restricted to a maximum speed of 20mph just in case someone had an accident. Heck, the cars would probably drive themselves and allow no human intervention for the sake of "ease of use".
Talk about screwed up priorities.
If someone wants to use SL to DDoS a website, it's none of LL's business. Send them a bandwidth bill, and turn over their identity to the feds if anyone complains.
Besides, you could just have the website register itself as "willing to be contacted" with LL's servers first. Or let us use two-way XML-RPC inside LL's grid.
I think a lot of people would pay good money for an Apache/mySQL server hosted on the same network as SL. The latency would be a dream compared to what we have now.
And if LL provided some sort of easy LSL<->CGI comms, it would be Nifty. No more polling or emailing crap back and forth.

Azelda, are you aware of Croquet? I've been following it since the developer release last month and it's interesting to see something in the same genre as SL but approached from more of a computing perspective. It helps see SL more clearly, really.

Anyway, just this morning someone on the developer mailing list posted this example of a 3-tier application wth Croquet:
http://www.dmu.com/croquet/cr20.html

It uses HTTP to go out to an ASP.NET page and back. I was looking at it and thinking this is what I'd like to be able to do in SL, and then I saw your post so I thought I'd share. Of course, Croquet is academic, so they can afford (for now) to push off issues like security, cost, etc. I appreciate that the Lindens have set up an actual working infrastructure that a lot of people currently use.

(Warning - the link above leads to examples in Squeak, a SmallTalk variant, which is weird)