What order are Nodes Syncronized in within the same NodeCollection?

[_vesuvias]

Basically is there a guarantee of synchronization order within a NodeCollection? I assume that there is and that it is based off the order in which the nodes were created. For instance in the SimpleChatModel the Node creation order is:

HISTORY_NODE_EVERYONE

HISTORY_NODE_PARTICIPANTS

HISTORY_NODE_HOSTS

TYPING_NODE_NAME

When synchronizing will I receive all of the messages in HISTORY_NODE_EVERYONE before I receive *ANY* messages for HISTORY_NODE_PARTICIPANTS? Will HISTORY_NODE_PARTICIPANTS send all of its messages before HISTORY_NODE_HOSTS sends its messages? When I say "sent" I don't as much what the actual network traffic is (I don't care about the actual packet order of arrival, that is your job AFCS developers ), what I really care about is whether ItemRecieve for HISTORY_NODE_PARTICIPANTS can get executed while HISTORY_NODE_EVERYONE is still receiving messages?

To take this a step higher in the hierarchy to the NodeCollection level does a NodeCollection need to be fully synchronized before another NodeCollection (that called subscribe after the first one) can get any ItemRecieve messages? If NodeCollection A subscribes before NodeCollection B is A guaranteed to get synchronized before B? Will A finish Synchronizing before B gets its first message?

I am starting to run into an issue where I need to make sure certain NODEs are synchronized before I start recieving messages in other NODEs. I of course can check for the dependencies on reception and simply defer execution until the dependency is sync'd but this will create a lot more code failure points than I really wanted. I was hoping for a simplier way of doing this.

                         Ves

[Former Community Member · Accepted solution]

Hi,

To start off answering , its recommended that the collection Node is fully synchronized i.e. the synchronization change event has been fired on it before you update your model or change anything in UI. We have built complex applications following this practice. So , I am not sure of an use case where you can't do the updating after your collectionNode has synchronized and update the model and the view only after collectionNode.isynschronized is true.

This will prevent any data dependency between nodes in a collection node.

Similarly , If data between two collection nodes is dependant to each other, you can make them under one collectionNode.

And lastly, we do not go for a specific ordering.

Hope this helps.

But please let us know the use case for yours.

Thanks

Hironmay Basu

[_vesuvias]

Hmm what I was trying to do specifically was for instance have a node that contained a list of arrays (NODE_LISTARRAYS). And have another node that represented the collaborative commands for those arrays (NODE_ARRAYCOMMANDS) such as push, pop, clear, etc. The second node (NODE_ARRAYCOMMANDS) clearly needs a reference to the first and is dependant (to do a pop() we need to specify which array to do the pop() on).

I need to process these commands (NODE_ARRAYCOMMANDS) in order they were received since array commands need to be executed in the received order for us to maintain sync with other clients. I was doing this in onItemRecieve without checking syncronization but I could imagine a scenario where I got a pop command for an array that hadn't arrived yet. Which is what prompted my question.

I think I understand now. If I am not synchronized on an onItemRecieve I need to stuff these arraycommand objects in an array, listen for synchronization and process them after getting the sync event. That's not exactly what I was expecting but not nearly as bad as I thought deferring execution might be.

So I'll add another law to my AFCS list of laws: Data Processing that is dependant on data outside the Node *MUST* happen post synchronization.

Thanks that actually did really help,

                                        Ves

[Former Community Member]

Hi Ves,

The AFCS dev guide mentions this in passing (3.1.5.1) but doesn't go into quite enough detail - we'll make a note to improve this for the next go-round.

Essentially, all items for a given CollectionNode (from all of its nodes) are synched in the order that they were published, irrespective of which node they were published to. You can actually put a breakpoint down in MessageManager.receiveItems to watch this - all items for the entire collection are received in one big blob, then pushed onto an array, then sorted according to their timestamps and order, then sent as itemReceive up to the collectionNode.

So yes, you could easily end up with an itemReceive for EVERYONE, followed by an itemReceive for HOSTS, then another one for EVERYONE. We make sure that they essentially come in the same order they did for people who were actually in the room at the time. For example in the chat pod, if I asked a question to the HOSTS node, which they answered on the public EVERYONE node, I'd want the items to be received in the right order, or the collective history wouldn't make sense.

For separate CollectionNodes, their synchronization are kept separate (one at a time), since they're the result of individual subscribe() requests - the advice here is that if you have a series of items that have some dependency on order of arrival, you should make sure they're part of the same CollectionNode (which makes sense). If you need A to finish synching before B begins, put those items on different collectionNodes and call their subscribe() methods in that order. So, you can have it either way, depending on how you want to set it up.

hope that helps

nigel

[Former Community Member]

Sorry, I'm answering questions in the order they came -

>> So I'll add another law to my AFCS list of laws: Data Processing that is dependant on data outside the Node MUST happen post synchronization.

This is not true - data processing within one CollectionNode can happen during synch (see my other post, order is preserved). Your case will work just fine (the whiteboard also has a lot of dependencies between messages of different nodes). What Hironmay is saying is that you'd likely want to avoid having your UI hooked up to your data pre-synch, since a flood of items is going to come all at once, potentially wasting CPU.

nigel