Responder Communication Framework White Paper
Responder uses events to communicate the existence of changes, rather than sending the actual changed data. Responder events are built upon IP Multicast, and IP Multicast is UDP-based which provides no reliability guarantees or ordering.
Following is a list of events that may be communicated by Data Services using the group IP address.
- Notify Network Change: This event notifies all Data Services and Prediction Services instances to refresh their versioned workspaces. When the user presses the Notify Network Refresh button in ArcMap or executes the Network Refresh command in Data Services this event will fire. Without multicast this will not work; the only other option is to perform network refresh in every Data Service through the web interface.
- Data Changed: This event originates from Data Services and notifies listeners that data has changed. This allows ArcMap and Responder Explorer to know that data has changed and will cause it to refresh at the next refresh interval. Without this event ArcMap and Responder Explorer will not refresh. This event doesn’t specify what changed, only that a change occurred.
- Dispatcher Changed: This event will cause Responder Explorer to update its list of available dispatchers.
- Rolled-Up Incident Notification: This event gets fired when an incident rolls up across regions (meaning that it may have changed ownership from one dispatcher's assigned region to another). This notification gets displayed in Responder Explorer.
- Callback Results Processed: The callback submit rules fire a DataChanged event when callbacks are processed.
- Query Service Started: Client applications communicate with IDataServices through a proxy class that permits redirecting "approved" (query-only) DataRequests to Query Services instead of Data Services for improved performance. This event is fired when a Query Service starts in order to aid in the proxy behavior. Basically it notifies the proxy that Query Services is now available and that it can attempt communication.
Like Responder PubSub, Responder events require a group address as described on the Responder Communication Framework page. However, the multicast group address MUST differ from the one used by Responder PubSub.
This group address is set in the service configuration files (e.g., Data Services, Prediction Services). This address must be different for each unique database configuration. However, the multicast group address must be the same in every configuration for a single database. For example, the following two bits of XML show different multicast addresses for databases named Marshall and Optimus.
<configuration name="marshall">
<multicast group="239.254.000.007" port="6679" ttl="2" />
<configuration name="optimus">
<multicast group="239.254.000.002" port="6679" ttl="2" />
However, if you compare these two database configurations in Data Services and Prediction Services configuration files, the multicast group addresses will be consistent. So, every configuration of Marshall must have a multicast group of 239.254.000.007.
