When Optimizely runs in a load-balanced environment (two or more servers), it relies on exchanging remote event messages between participating servers. It could be that a cache item was removed, content changes were published, product prices were updated etc.

On the old Optimizely CMS platform (pre-version 12), two or more on-premise servers would exchange event messages, either through a WCF integration layer for on-premise servers or an Azure Service Bus or Amazon SNS topic for cloud servers.

Starting with Optimizely CMS 12, the WCF integration is not available anymore. As of now, only an Azure Service Bus integration is publicly available, making Optimizely CMS usable only for cloud hosting and for single-server on-premise hosting.

An Optimizely team is currently developing and beta-testing an event provider based on the MassTransit platform, which can be used on-premise.

I thought it would be interesting to provide a new low-level, high-performance event provider, based on .NET sockets. For some background on event providers, I once wrote a similar blog post for the then-current version of the platform.

Using .NET sockets

The WCF framework was only built for Windows and is not being ported to .NET 5+. So that will not work, going forward.

But the old WCF event provider had one good thing going for it: It simply serialized event messages and sent them over raw NET sockets (UDP or TCP). This meant there was no need to install, configure and maintain a separate piece of message broker software.

Generally, the downside of sending messages directly, without a message broker, is that a missed message will be missed forever. But on an internal network packet losses should not occur (that would be a much bigger problem for the network administrators).

To mimic a similar mechanism, I created some very simple, very efficient event providers that work directly on raw .NET sockets.

At the time of writing this, there are two available event providers (source code available here):

• UdpUnicastEventProvider (unicast; one-to-one)
• UdpMulticastEventProvider (multicast; one-to-many)

Each has its own pros and cons, and you need to decide which fits best into your hosting environment.

Choosing an event provider

The most appropriate choice of event provider depends entirely on the network design and the number of web servers.

Multicast

If all servers are placed on the same network, try using multicast. Multicast is a very efficient technology and the multicast event provider have minimal configuration overhead. The event provider just needs to point to the same multicast group IP on all web servers.

The nice thing about multicast is that it is sending one event message to one IP address, and the network router takes care of distributing it to servers that “want to listen”.

Though, in some organizations the network administrators disable multicast routing. In that case, consider using Unicast instead.

Unicast

Consider a scenario where one or more webservers are confined to a strict DMZ network, while an edit server is placed on an internal network. Multicasting will almost certainly not be allowed in this network design. Instead, we can use unicast.

The unicast event provider works by sending copies of an event message to each known server, one-to-one.

To do this, the unicast event provider needs a list of related servers in order to send messages to each server. This is usually done in config transform files, unique to each server. This way each server will have knowledge about all other servers than itself, and the event provider can send event messages directly to each server.

In some organizations, the network administrators will even block unicast UDP traffic between servers in separated networks. In that case you may need a TCP-based event provider or an event provider based on a separate piece of message broker software.