Please suggest a way to walk around incoming prim-to-prim email bug

[dk201]

Hello everyone, I am writing an email based vendor machine recently. Say i have my email handler in prime SERVER and multiple client prims CLIENT(S) in different sims. When ppl click any CLIENT, an email will be sent from CLIENT to SERVER. And SERVER will handle the email and deliver the item.

However, i noticed the script in SERVER will stop handling incoming emails after sim restart. Reset scripts wont help either. So i found this jira post https://jira.secondlife.com/browse/SVC-23?

Seems this is a known bug and LL will never fix it... so here is my question, is there a way to implement reliable email based vendor or i should try to find an alternative, hopefully secure, way?

Thanks in advance,

[Rolig Loon]

There is one way, but it's only accessible if you happen to have all your vendors and your server on regions where they have access to the same Experience.  If that's the case, then you can save the URL of the server in KVP periodically or after any script restart.  Have the vendors query KVP to verify the URL before they send a message.

[Qie Niangao]

If I understand correctly, these CLIENTs are currently communicating with the SERVER directly by email, not http, so it's not that they're losing an ephemeral URL every sim restart (the http problem) but rather that, very rarely, incoming email to an object gets wedged. I had this problem for years and only worked around it by having redundant servers (for real time reliability) and then manually fixing the wedged servers with the method described in that jira (attaching them, going to a different sim, coming back and dropping them, so as never to change their UUID and hence email address). That's a real pain, but I never had it fail.

On the other hand, the emails exchanged with my servers were only to re-establish those ephemeral http URLs, and the usual solution for that was to use external web services as registry for the in-world servers. (I was too cheap and lazy for that.) So if you're okay with switching to http for messaging, that's the typical approach.

I do, however, completely agree with Rolig in favor of the Experience "Persistent Store" (aka "Key-Value Pairs") function if your application can support each CLIENT and SERVER being on land enabling your Experience. Then it's up to you how you want to handle the messaging through the KVP: either use it as that registry of http server URLs, or to mediate the messaging directly as shared memory communications.

[dk201]

What does KVP stand for? 

[dk201]

Thanks for explaination. I would like to try that kvp way. Is there an good example for me to start? Thanks,

[Rolig Loon]

---

dk201 wrote:

What does 

KVP stand for? 

---

Key - Value Pair  .  See http://wiki.secondlife.com/wiki/Category:Experience_Tools 

[Rolig Loon]

---

dk201 wrote:

Thanks for explaination. I would like to try that kvp way. Is there an good example for me to start? Thanks,

---

There are short coding examples in the LSL wiki for each of the persistent storage (KVP) functions.  For example >>> http://wiki.secondlife.com/wiki/LlReadKeyValue#Examples .  You'll have to write your own script for building KVP into your communication system, but it's not difficult conceptually.  Think of it logically as something quite similar to reading the stored information off of a notecard.  The only difference is that your dataserver event will want to read from KVP instead of a notecard. Your server script just needs to use llUpdateKeyValue to refresh the KVP whenever it is rezzed or restarted.

[dk201]

Thanks a lot! Final question, how to secure my message if i use KVP? As i know, KVP is still based on http, so message is kinda exposed. do i need a encription script or there is a better way?

[Qie Niangao]

You could get an SSL-encrypted connection (https) using llRequestSecureURL() but I've only ever considered that relevant for communicating with certain external services, not for communication among scripts within the Linden Lab network, which seems pretty safe to me. (That's assuming you control the client and server objects so nobody else's scripts can be installed inside them. If that's not the case, SSL may not be good enough anyway.)

As much as I favor this approach, I would just caution again that it will only work if the locations of all clients and servers can enable the Experience for which your KVP is compiled.

[Rhonda Huntress]

You can do some simple encryption with XOR

http://wiki.secondlife.com/wiki/LlXorBase64

There is even a brief description on how this works for encryption at the bottom of the page.

[Rolig Loon]

I agree with Qie that encryption doesn't need to be fancy, if you need it at all.  All of your communication is internal to SL.  You're never exposed to outside threats.  You could hash your messages easily enough, but I probably wouldn't bother. 

Qie's more important note is his reminder that you do need have both your server and all of the communicating units in the same Experience.  If they aren't, you obviously won't have access to the KVP.

[dk201]

Thanks guys, a lot of handy information from your answers .