The cluster SNACs bracket a set of transactions that should be handled by clients as a group to avoid "flashing" the user's screen.
They help in cases where multiple instances are online, or when the host is making updates for the client, so the receiving client knows several changes are happening at once. These SNACs have nothing to do with the actual database transactions. In particular, non-receipt of an END_CLUSTER does not cause the database transactions to be rolled back. The cluster SNACs bracket a set of transactions that should be handled by clients as a group to avoid "flashing" the user's screen.
They help in cases where multiple instances are online, or when the host is making updates for the client, so the receiving client knows several changes are happening at once. These SNACs have nothing to do with the actual database transactions. In particular, non-receipt of an END_CLUSTER does not cause the database transactions to be rolled back.
the start_cluster end_cluster snacs are optional. if they do not appear in stream of to client, then client should handle each insert delete update snac as it arrives. wait for end_cluster, or after a timeout period before processing all insert, update, deletes.
From Aleksandr Shutko: SNAC(13,11) FEEDBAG__START_CLUSTER
Use this before server side information (SSI) modification. Also
you should send SNAC(13,12) after SSI modification.
You could also use "import" transaction mode to add contacts requiring authorization.
Just add 0x00010000 to snac data to start import transaction. See also snac list for
SSI service here.