Jump to content

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


dk201
 Share

You are about to reply to a thread that has been inactive for 2245 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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,

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites


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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2245 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...