No delay for local e-mails

Communication in LSL is a pain. We miss a global information infrastructure. Scripters have to choose between limited-range chat, slow mail, or web-dependent HTTP. Network protocols require fast and bi-directional transmission of messages.

Mail is the only choice for grid-wide, web-independent networks. We have to use lenghty and convoluted scripts to work around the 20s delay penalty, rezzing temps objets, encoding keys in chat strings... But we do it. So this delay is no longer useful, but just add code and complexity.

Suppressing the 20s delay for local mail (but keeping it for outworld mail as an anti-spam feature) would result in simpler, more efficient scripts, and ease the development of networked systems.

The reason that throttling is there is to restrict the potential for abuse - Linden Labs could become a serious heavy-weight source of RL spam if the limit were lifted. Don't forget that llEmail() can email ANYBODY, not just an in-world SL object.

If you need faster interaction, you can use RPC or distribute your messaging via an external server. That's what I did for my stuff, and the message lag went from three minutes to three seconds, not to mention being impervious to arbitrary UUID changes in the target devices.

I think that's what he was saying - remove the 20 second delay only if the address sent to is @lsl.secondlife.com.

There could be some problems with spamming objects, mind you..

Spamming wouldn't be as much a problem as DoS attacks against the sim.

I hadn't thought about that one. That's probably why many of our communications functions have forced stalls in them.

Yes, Yumi. Mail from lsl.secondlife.com to lsl.secondlife.com. That's local mail.

XML-RPC? Depends on an external server. What if the server fails, is down or, in the long run, is removed from the internet? How do you update the URL in hundreds or thousands of objects? Who operates the server and how? What about privacy?

Spamming? Second Life is a heaven for spammers. We give our key to millions of objects. Sensors and volume detect may get it silently. What do you know about them? Do they collect our keys? Send them out? Every object you buy with nomod script may contain a troyan. So, it's a miracle we are not more spammed. And as a postmaster, i'm very, very concerned about spam.

An example where the 20s delay stinks: Networked information kiosks. You want to make information available grid-wide. A kiosk is clicked, then send a short message to a central server. The server delivers a notecard to the agent. And the kiosk is down for 20 seconds. In welcome areas, in schools, kiosks are clicked more than once every 20 second.

We can defeat the 20s delay by using mailers prims. That's no secret. The code is on the LSL Wiki. So this protection is not real security, just a pain for scripters. Throttling the MTA (Mail Transfer Agent) is, and Linden does it.

Personally, I would rather them use named pipes so scripts can communicate with one another. They are secure, can be private/semiprivate/public, and are very fast. They already exist in all Linux implementations, and it would be trivial to manage them globally.

I think something as specific as "named pipes" is way overspecifying, but a secure higher-performance object-object communication mechanism is necessary.

Perhaps llInstantMessage to an object should generate an "instant_message(key sender)" event?

Even the ability to IM objects in the same sim with no delay would be a HUGE step forward, and would not require any tracking of object presence in order to find out where an object is. It won't help in the global scheme of things but it will help.

As to the original suggestion, I'm not sure having unthrottled e-mails flying around is such a good idea either really, sending an e-mail to an internal server and an external one doesn't really much more resources, as it's the same process for both.

What we need is some way for an object to register or generate a "location key". This is much the same as an ordinary key, however some part of it specifies the simulator in which the object can be found (I thought part of the UUID was supposed to do that already but I keep get differing opinions so have to assume not). So you'd have an object, it generates a location key for itself, you put this into other objects, now when they call llInstantMessage() on this key, the IM knows where to go right away.
Even this however would require some degree of throttling, as it is still increasing the amount of potential inter-sim load from objects passing messages around. I don't have any network statistics though, this could be a non-issue depending how much communication actually occurs within the network (as internal networks tend to be nice and fast).

I did mention this in a post on Linden Answers a while back. The justification I got back from LL is that a novice scripter is not likely to implement a process farm by mistake, whereas it could be relatively easy for a runaway loop to send huge numbers of e-mails if there was no time restriction.

In answer to Argent Stonecutter and Haravikk Mistral : of course, pipes would be a huge improvement. But also a major feature to develop, test and support. Same for IM. I would love to see them implemented. But that's not for tomorrow. In the meantime, i'm proposing a minor change.



A novice scripter may collect all agent keys every minute in a 96m radius and oops... have them notecard-spammed with a runaway loop. Even when they leave the sim! So, Linden shoud delay llGiveInventory for 20 seconds. The justification goes nuts.

Linden already throttles mail at the MTA level, as explained in http://slhomepage.com/lsl/llEmail.htm : «Through a linden, I was able to understand that the limit is 1 email / second for an extended amount of time. You will then be throttled until the day's email rate for you has slowed down to that rate, thus, at 12:00 AM PST, the throttling list is cleared out.»

Every experienced scripter use linked or temp rezed mailers. Take a look at ChristopherOmega's Email Extension Module. Add to that the chat codec. Grand total: 617 lines of code to bypass the 20s limitation! Wow!

Um, IM is already there. The only thing that's missing is an event handler. The changes to indra.y and indra.l and lscript_execute would be minor. It's hardly a major feature.

Eh? Are you be talking about server code there? Has it been opensourced without me noticing or something?

The compiler and the LSL code interpreter is in the client.

The rest of the infrastructure for llInstantMessage() to prims as well as avatars already exists, in llInstantMessage() and llEmail().

But clients don't actually run the scripts... do they!?

Does that mean thet bytecode scripts can be stolen from objects?

How does it decide which club patron is running the danceball script?

The client doesn't run the scripts, but they have a copy of the execution code anyway. I suspect that this is simply common code for the client and the server... it would be much harder to remain consistent if they had independant implementations of the scripting code.

Oh, that's why the notification was still in my inbox, forgot to reply here.

So if it's a minor change and the code in the client's likely a mirror of the server code, couldn't someone implement it and send LL the update for approval/inclusion?

Given that they won't take my bug fix for the screwed up LSL constant syntax...

That sucks, something one of the Lindens said once indicated fixes done by users could be submitted for testing and inclusion.

That system isn't fully in place yet.

Unless you've uncovered and fixed a glaring new bug, you're code likely isn't being rolled into the official client in the nearterm.

Has there been an indication of when it will be? I'd have thought taking advantage of talented users in that way would have been given more priority, seeing how much work SL needs doing an' all.

*shrug*

I wonder if a user-run testing group was put together for user-created fixes etc. it'd be able to get some recognition from LL and stuff like this could get done without a noticeable drain on official resources...

The fix I submitted fixes a bug similar to the Pentium F00F floating point bug, one that allows scripts to compile successfully but produce completely erroneous results. Not the sort of thing you want in the loop where money transfers are involved.