This provider supplies a model for object-oriented interface definitions and configurable interprocess communication methods, without the need to change code. This provider is the default provider.
## Configure the event system
The Optimizely Content Management System (CMS) event system is used for distributing events between websites in a multi-site and/or load-balanced scenario. The configuration consists of two parts: **subscriber** and **publisher**. An Optimizely server can be both subscriber and publisher.
The Subscriber works as a WCF Server, therefore configure it as WCF Service. To configure the Optimizely Event System Subscriber, make the following checks/adjustment to the Optimizely CMS _web.config_ file:
In the **<configuration>** section, ensure the following **system.serviceModel** section exists and insert the subscriber WCF Service element. Mandatory values are shown in the example (for example, contract name and name of WCF service) and the asterisk (\*) indicates the custom value. See the Microsoft documentation about WCF configuration for more information.
In the **<configuration>** section, ensure the following **system.serviceModel** section exists and insert the subscriber WCF client element. The mandatory values are shown in the example (such as, **name** and **contract** ) and the asterisk (\*) indicates the customer value. See the Microsoft documentation about WCF configuration for more information.

## Use UDP for remote events
An example configuration using UDP multicast. Be sure to use unique port numbers if you have multiple installations on the same network.
Note
UDP multicast is not supported in Azure Virtual Networks.
**Code example for CMS 11.1 and higher**:
**Code example for CMS version 10.**
## Use TCP for remote events
An example configuration using TCP as the protocol. In the following example, the server with IP 192.168.1.1 is configured to communicate with servers 192.168.1.2 and 192.168.1.3. Each server should have an unique configuration to expose 1 service and have multiple clients to communicate with other servers.
Server 1 example:
## Use a separate configuration file per IIS web site
You can have different configurations for different IIS sites by moving the configuration to a separate file prefixed with the name of the IIS site followed by a underscore. This type of configuration is useful in the multi-site and/or load-balanced scenario when sites share a physical path. Name the file _[IIS web site name]\_web.config_ where the name is the name of the IIS site.
## Use a separate service name per IIS web site
You can have different configurations for different IIS sites by prefixing the name of the service with the name of the IIS site followed by a slash. This type of configuration is useful in the multi-site and/or load-balanced scenario when sites share a physical path.