What order are Nodes Syncronized in within the same NodeCollection?

Question

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

Answer 1

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