Do link-messages arrive in the order sent?

A very quick question if I may.

Script-A is firing off llMessageLinked messages, ScriptB (in the same prim) has a link_message event waiting to receive them.

Is script-B *guaranteed* to receive the link messages in the same order that script-A sent them?

I assume "yes", but I have seen that llSay's (needed for object to object comms) are not order-guaranteed.

Many thanks for any input you can provide,
Cale.

Not sure about the actual answer.

However, you can add an index to the beginning of the link message and set the receiving script to order the incoming link messages based on the that index.

Yes llMessageLinked messages will arrive in the order sent. llSay's are not guaranteed to arrive in the order they are said So with these it would be useful to include a sequence number at the front and queue them in a list for handling if you get one (or more) out of sequence.

Well, actually, no, they are not *guaranteed* to arrive in the order sent, but it is highly likely that they will, unless the sim is VERY lagged or something else weird is going on.

So, practicallly speaking, I should assume the arrival order is random. I mean, I don't know about you, but my least favourite programming job is debugging the code that works perfectly in 999 cases out of 1000.

With event-driven systems, you cannot generally take anything for granted about the arrival or ordering of events into event queues. You may get an event; you may not. You may get one event before another; you may not.

*Practically*, they still are deterministic systems, because the underlying platform is a deterministic machine. However, there are complexities in it which can cause exceptions to occur and, thus, you cannot guarantee that those exceptions won't happen.

You can design your scripts around the notion that they *should* arrive in order, but your scripts should also take into account and be able to cope with the uncommon anomaly where they don't.

This is important, so please forgive me if I check my understanding of what you have written.

We have cases of link-messages simply *dissappearing* in LSL? (Outside the pathological case of a sim-crash epsilon after a link-message was sent I mean.)

I ask, because a lot of the code I see out there in the wild, that does seem to work, does *not* have "I sent this", "yep I got it" type handling of messages. I have a product that turns a particle effect on and off in response to a link message. I shudder to think how many hours I've put into testing the product , and I've never seen that link message go missing as it were.

The "I sent it", "I recieved it" is something to be careful of. There comes a time when you just have to accept that it go there or didn't. This is a common problem in any network programming. think of it this way, you have 2 armies that need to talk to each other, with a third, hostile, army in the middle. Army A sends a message to Army B saying to attack at dawn. Army B sends a message back to Army A saying that they received the message. Army A then sends a message back to Army B saying that they got their message, Army B sends a message to Army A, saying that they got their message about getting their message... you can see where this is going.. if you do confirmations, you'll just be sending those out eventually.

Now, this being said, you CAN "serialize" the system, by having Message A send a message, if it doesn't receive a confirmation in x amount of time, try again, repeat this for a certain amount of time, then consider that message lost. If it does receive a confirmation move on. It all comes down to where you feel comfortable that a message won't be lost, and just faith that it won't.

It's always dicey to assume anything about how a function is implemented, but nonetheless: If I were implementing link messages--which are necessarily sim-local--I'd have to work extra hard to dream up a scheme that could get them out of order for a single-threaded source. (That's in contrast to channel messages that must use network queues to support inter-sim communications.) So, I wouldn't waste CPU or memory checking for the *sequence* of link messages. But whether they all get delivered: if a source is generating them faster than a sink is consuming them, eventually, somethin's gotta give. Maybe llMessageLinked() blocks, maybe not.

Under normal circumstances, no. However, it *can* happen under not-so-extraordinary situations, too. Missing messages would be far more common than out-of-sequence ones in your situation, though. It would take some seriously screwy set of events to cause them to become out of order, but my point was that there was no *guarantee* that they would stay in-order; i.e., it was *possible* that they would become out-of-order, not *probable*.



Yeah, it's a safe presumption. Good enough for most common uses without worrying about it. It's just not *guaranteed*, which is what your original question was predicated on.