Comms mechanism in a game which spreads over 100m? Is email the only option?

Hi,

If I'm trying to establish a game with devices spread over more than 100m then is email the only comms mechanism?

It doesn't seem to be appropriate due to:
- limits on number of emails in inbox? (from some posts I've seen)
- "After sending the email, this function delays the script for 20 seconds." - not fast enough

Comments? Ideas?

Would it be better to link objects together < 100m using llShout and relay message across the distance?

Thanks

My skyhook uses relayed listens to coordinate lifting avatars up a 500m cable.

Relays would probably turn out the best, if you know where things will be. Do something to make sure you don't get looping messages.

If you are sending info long distance infrequently then email could work out ok - have a seperate script send the email and get locked up for the 20 sec.

Another random idea I was thinking about in a similar situation but didn't end up implementing: send information within a sim using llRemoteLoadScriptPin (also has a delay, but its much less than email). I haven't tested it, but I would imagine you can load a script up with the data and have another script send a copy of it over to the target prim, where it link messages its data out again.

You couldn't add data to a script then send it, as a new instance of the script is what arrives, clearing all variables and states it might have had if it was running on the sender. But you can pass data by WHICH script you send. That's rather limited, though.

I've done relays as well. For scripts embedded in a location that need to communicate fast and often, this works the best. If the messages are few and not time-sensitive, or if they need to span a distance of several sims or more, email is really the only option.

Object to object communication is one of the big holes in LSL right now. This is known by Linden Lab, and I've heard several times that they are working on it.

What I'd like to see, myself, is a sim- or parcel-based data storage system that any permitted object can access. Not only would it provide needed permanent storage for information gathered and held by scripts, but it can act like a pipeline for O2O signals.

I tried relayed listens once, but I'm a terrible scripter and it was late at night, so I made them all listen and say the same thing..

Tethys was running slow that night..

Is there an inherit security issue with relaying (I'm assuming using llShout on a channel)? That is someone could listen in and discover the syntax/protocol you're using and then spoof communications. E.g. if you were relaying an update regarding a users high score, including the user ID and the score?

Sure, if you think someone is going to care that much to try to break it. There are lots of security things could could do about it, randomising channels, using very large channel numbers (and not telling anyone what they are) etc. There are also a couple of crypto-like things on the wiki, but I've not looked into it.

People doing ATMs, the Notary and so on have, I'm sure, successfully dealt with security issues if you want to get really serious.

thanks Seifert

Someone I know uses a 'messenger bullet' system for mid range communication. You fire a bullet roughly towards the next point, it either uses a sensor to get close or shouts out it's message when it gets to where it's meant to be. I'm not sure it's an ideal situation, although with temp on rez and a cluster of them you could easily blanket the next sim over to make sure the message propogates that way.

It's sort of a flange, but it's faster than email, not really hugely laggy and ought to be fairly robust. I guess it can also be used over longer distances too, but I've never really tried it. THere iwll be issues with no script zones too I guess.

Ok, if it is person to person com. Use Multi IM script.. Very simple
This allows intersim comm too! Fast.

If it is prims to prim and there is going to be very few e.g 1 or 2 use multi mail!
Somthings used by servers to send 100's of mails a min. Laggy, Good if you need a server and only 1.

Else use relay..

On the issue of security: Communications in SL can be secured to a variety of levels and confidences. If you're just communicating score, turn and state information around, then you just need the data authenticated. LSL's llMD5String and a shared secret are enough to do this.

If you need to transmit concealed information, that may be more difficult. LSL's facilities for real encryption are pretty thin. Some simple cyphers are possible, but anything serious (like what would be needed for banking transactions) are probably out of the question.

Feel free to contact me here or in-world if you'd like some consultation on this stuff. I have more than a little experience... I'm the creator of the SL notary!

Hi Zarf - I guess you would need to be careful about your inter-object protocol to avoid a "replay attack" I guesss. That is if someone were listening on the channel, got the string (couldn't interpret it) but just keep repeating it (e.g. llShout) this could a problem.

I'm assume the concept you were referring to was sending in a string (e.g. within an llShout) the data + a checksum, the latter being calculated using the llMD5String approach. So the shared key for this would be the llMD5String "integer nonce" parameter?

Tks

Greg -

Here's the outline of how you do authenticated communication from Amy to Bob:

* Prior to communicating, you share a secret with only Amy and Bob

* 1. Amy prepares a message by computing the MD5 of it and saving it.
* 2. Amy transmits the message to Bob
* 3. Bob receives the message, and picks a random challenge string, and sends it back
* 4. Amy receives the challenge, and computes the MD5 of a combination of the challenge, the MD5 of the original message sent, and channel identifying information, and sends this back to Bob.
* 5. Bob makes the same computation, receives the reply, and checks if they are the same.
* 6. If they are the same, Bob now knows that Amy sent it, and that it wasn't tampered with in route, and that it isn't a replay.

Of course, the devil is in the details. However, the nonce argument to LLMD5String is almost totally worthless for any of these operations - it is just too small, and applied to the string in the wrong way, to be of any cryptographic use.

thanks Zarf - you seem to know your stuff here

What would you recommend as a "reasonable" (not going overboard) approach just for having remote sensors communicate to a controller objects which is updating a scoreboard & highscores? (i.e. just to prevent someone their own highscore). Perhaps just the approach you mentioned?

Thanks