GetServerChanges

(RPC Manager Library)

Description:	Launched by RPC Manager on a service server to obtain the service's synchronization data (i.e. called by RPC Manager during startup synchronization on a server to get the package of RPCs that create a synchronizable state on the client which is in step with the server).
Returns:	See comments
Usage:	Steady State only.
Function Groups:	Network
Related to:	Adding Server-Only Synchronization
Format:	GetServerChanges(RevisionInfo, PackStreamRef, Client)
Parameters:

RevisionInfo

Required. The revision information from the GetClientRevision call made on the synchronizing client.

PackStreamRef

Required. A pointer to a variable to obtain changes.

ClientName

Required. The name of the client.

Comments:

This subroutine is expected to be found in the object value of the caller of RPCManager\Register. It should not be called as "\RPCManager\GetServerChanges", but it may be appropriate to call it within the scope of the relevant service "<service scope>\GetServerChanges".

GetServerChanges() should not be written as a subroutine, as it will run on the RPCManager thread, thereby suspending external machine communication during synchronization.
If your GetServerChanges() request takes a long time, this will lead to a reduction in RPC throughput during RPC service synchronization, which may have undesirable effects. If GetServerChanges() is instead written as a launched module that slays itself when complete, the RPC thread will continue to service other RPC requests while you are building your synchronization data package.

Further, if GetServerChanges() is written as a subroutine, the RPC thread can be suspended while running your GetServerChanges() script, allowing your service thread to get a time slice and modify the service data that you are attempting to sample. This may cause two PCs running the same service to end up with mismatching data.

You must write GetServerChanges() as a launched module and call \RPCManager.SetDivert() as soon as you have finished sampling the synchronizable data for your service. If there is any possibility that another execution thread in your application can modify the data that GetServerChanges() is sampling during building of the synchronization package, you must protect the acquisition of the synchronization package with a CriticalSection().