Sending 10 Strings of Size Up To 100 Chars

[GManB]

I need to send 10 strings, max size 100 characters but average size much less, to another object in the same region. I have been using llRegionSayTo successfully for a while now for small single strings. But, I am wondering if anyone has any suggestions for sending the 10 strings.

I can see two obvious options:

1. Concatenate the 10 strings with a delimiter separating them and send the possibly 1K long string in a single message then parse out the strings in the receiver.

2. Do ten individual sends.

Any preference for either of the above? Or another suggestion?

Kind of a related question. What is the likelihood that these kinds of messages disappear without a trace? Would it be best to code these sends using some modification of the two-phase commit protocol?

 

Thanks,

G

[Mollymews]

27 minutes ago, GManB said:

1. Concatenate the 10 strings with a delimiter separating them and send the possibly 1K long string in a single message then parse out the strings in the receiver.

recommend going with method 1.  Max. length of a Say message is 1023 chars

max length of the concatenated string is 1010. (100 chars + 1 delimiter) * 10

[Qie Niangao]

Agree with @Mollymews on option #1; the only thing that comes to mind would be if either the sender or recipient is so tight for memory that they can't handle an extra 1K string, but that would be a bigger problem anyway.

2 hours ago, GManB said:

What is the likelihood that these kinds of messages disappear without a trace? Would it be best to code these sends using some modification of the two-phase commit protocol?

I've never worried about this happening spontaneously, but I suppose anything is possible. What absolutely will happen, though, is an untimely sim restart. So the sender might think it's transmitted a string that may or may not be received before the sim restarts. I don't know if there's any guarantee that the "sent" message will be waiting in the recipient's event queue when the sim comes back. That raises another condition where it could happen: event queue overflow, where the recipient is so flooded with other events to process that the message ends up in the bitbucket. I'm guessing that's not a concern in this case.

[Profaitchikenz Haiku]

22 minutes ago, Qie Niangao said:

What absolutely will happen, though, is an untimely sim restart

Or, throttling if too many messages have been sent. I've had this before with a railway system that sent messages to and from vehicles, signals and stations.

My suggestion is prior to sending the message, count the total number of characters in the concatenated strings, including the seperators, which amongst other things will warn of a string-truncation problem. Send the message. The receiving object counts the string and sends as a reply to the sender the number of characters it has received. The sender needs a queue of messages , recipients and lengths, and only removes a message from the queue when it has got an expected reply.

[Mollymews]

agree with Prof

acknowledge receipt of the message when is critical to the app

[GManB]

Thanks all for the suggestions everyone!!

A little more detail. I'm creating a game for an event. A .'Main Board' and up to 30 players, each with a game HUD. The 10 messages are sent to the HUD when the players register. When a new 'round' starts the messages from the Main Board to the player HUDs are smaller; 1 of the up-to-100-char string and a couple integers.

During the registration process I can lock the Main Board until it and the new player HUD have completed the send and ack of the initialization message.

When a new round is started the Main Board has to send up to 30 of the smaller messages. The Main Board and each HUD have a shared, unique to each player HUD, large negative number for a channel.

This game is intended to be played during an event thus the sim might be pretty busy And I do want to make sure each HUD gets the new round info before the round starts. The starting and completion of a round are controlled by a human selecting options on the Main Board and I would expect a round interval to be about 10 minutes. So, the Main Board has lots of time to make sure things are correct.

All other suggestions or ideas more than welcome!

 

Thanks,
G

[Qie Niangao]

Those first ten messages that get sent to the HUDs upon registration: Are they the same for everybody? And what's the origin of the information in those messages?

If they happen to all be the same, it may be worth looking for a way to broadcast the information. I'm assuming the players won't necessarily all register at the same time, so it wouldn't be a synchronous broadcast (llRegionSay()), but... anyway, two things came to mind:

• First is populating Key Value Pair strings in an Experience persistent store. In fact you could do that even if the messages are different for each player, but it only really wins over individual messaging if they'll all end up read the same information anyway. Note that the players don't need to be involved in the Experience, just their HUD script needs to be compiled to use the Experience's KVP store.
• Second, if the message information happens to be derived from a notecard, you could simply hand the UUID of that notecard to the player HUDs and let them read it on their own. This is clearly irrelevant if the messages contain information derived by the Main Board script at runtime.

[GManB]

2 hours ago, Qie Niangao said:

Those first ten messages that get sent to the HUDs upon registration: Are they the same for everybody? And what's the origin of the information in those messages

• First is populating Key Value Pair strings in an Experience persistent store. In fact you could do that even if the messages are different for each player, but it only really wins over individual messaging if they'll all end up read the same information anyway. Note that the players don't need to be involved in the Experience, just their HUD script needs to be compiled to use the Experience's KVP store.
• Second, if the message information happens to be derived from a notecard, you could simply hand the UUID of that notecard to the player HUDs and let them read it on their own. This is clearly irrelevant if the messages contain information derived by the Main Board script at runtime.

Qie, Thanks!

The messages will be from a notecard and unique for each HUD and the ten for each HUD are different as well.

The Experience KVP sounds really interesting, I will check it out.

Also, the idea of passing the UUID of the notecard to each HUD and a unique list of lines (the nc has one message per line and will live in the Main Board contents) is very interesting. The initial message will be smaller and I don't have to do the dataserver event process to read the 10 lines but can have the HUD do that. Actually, now that I think about it, if my assumption below is correct, I could just hardcode the UUID of the nc in the HUD script and have the Main Board just pass the list of 10 unique lines...

Will the UUID of the nc in my inventory be the same when that nc is in the contents of the Main Board? I.e., are notecard UUIDs, like texture and sound UUID's, global to all SL and persistent even if I at some point in the future delete the nc from my inventory?

 

G

[Qie Niangao]

4 hours ago, GManB said:

Will the UUID of the nc in my inventory be the same when that nc is in the contents of the Main Board? I.e., are notecard UUIDs, like texture and sound UUID's, global to all SL and persistent even if I at some point in the future delete the nc from my inventory?

The notecard UUID changes every time it's edited, and the previous UUID will continue to operate on the unedited version of the notecard.

You can test what happens when you add a notecard into multiple object inventories without editing it. I'd be surprised if there are any new UUIDs because, without editing, there shouldn't be any new assets created, only additional references to the same asset.

So in theory you wouldn't need to add the notecard to the inventory of the Main Board, even, just let the Main Board script know the UUID of the notecard you want it to use, but personally I'd probably keep the current "master" notecard in the Main Board, just so I could edit it there if necessary, and I'd have the Main Board pass the current notecard UUID to the HUDs. But you're right, if the notecard really is static, its UUID could be hardcoded in the HUD script.

I think notecards behave like textures in that they should remain valid to reference through UUID even if the original is deleted from all inventories, but I'd try not to exercise that if I could avoid it, only because I'm old enough to remember when some script-referenced texture UUIDs were lost to some error in asset garbage collection.

A quick note about Experiences: They're almost all "land scoped" which means any place where this game is played would need to enable the Experience on the land. If this game is used multiple places, that's unfortunately a hassle.

[GManB]

4 hours ago, Qie Niangao said:

The notecard UUID changes every time it's edited, and the previous UUID will continue to operate on the unedited version of the notecard.

Wow, that's a lot of versions of notecards...

 

I put the UUID of the notecard in the HUD and did not out the notecard in the Contents of the HUD and it works as you said it should.

I think I would prefer to keep the master (with verison numbers) in my inventory..

Thanks, this has been helpful.

G