Server-sent Events

The technique described in Polling the Previous Link helps to ensure that polling from multiple clients places the least possible strain on the Content Store host. Polling in general, however, has limited scalability. If the Content Store is required to respond to frequent polling requests from a large enough numbers of clients, then performance will suffer.

Server-sent events are a standard method of avoiding the need for polling, introduced with HTML 5. Instead of polling a server for changes, a client can open a persistent link to the server and receive notifications of changes via that link whenever they occur. This has two advantages over polling:

Improved scalability on the server, since the server only needs to do something when a change occurs, rather than every time it receives a polling request.
Improved response times on the client, since there is no polling interval delay: the client gets notification of a change as soon as it occurs.

Using server-sent events to get notification of changes to Content Store change logs is very straightforward. All change log feeds contain a link that can be used to set up a persistent server-sent events connection to the Content Store. Sending a change log GET request like this, for example:

curl -u user:password -X GET http://host-ip-address/webservice/escenic/changelog/section/481

Returns, in addition to any changes, a link to an event stream.This link always has the following attributes:

rel: Set to http://www.vizrt.com/types/relation/changelog
type: Set to text/event-stream
href: Set to http://host-ip-address/webservice/escenic/changelog/sse

For example:

<feed>
  <id>http://host-ip-address/webservice/escenic/changelog/section/481</id>
  <updated>2016-06-07T09:08:42.800Z</updated>
  <author>
    <name>Escenic Content Engine</name>
  </author>
  <link rel="self" href="http://host-ip-address/webservice/escenic/changelog/section/481/before/16677017?count=10"/>
  <link rel="previous" href="http://host-ip-address/webservice/escenic/changelog/section/481/after/16677016?count=10"/>
  <link rel="next" href="http://host-ip-address/webservice/escenic/changelog/section/481/before/14914468?count=10"/>
  <link rel="http://www.vizrt.com/types/relation/changelog"
    href="http://host-ip-address/webservice/escenic/changelog/sse"
    type="text/event-stream"/>
  <entry>
    ...
  </entry>
  ...
</feed>

Sending a GET request to this URL sets up a persistent link over which the Content Store can send notifications. If you send a GET request using curl, for example, you will see that curl does not return control to the command line prompt, but "hangs", because the connection that has been created has not closed.

curl -u user:password -X GET 'http://host-ip-address/webservice/escenic/changelog/sse'

If you now create a new content item, or make some other change from Content Studio or from a different terminal window, you will see that the change is reported using the open connection:

curl -u user:password -X GET 'http://host-ip-address/webservice/escenic/changelog/sse'
data: http://host-ip-address/webservice/escenic/changelog/section/22

Changes will continue to be reported in this way for as long as the connection remains open.

Server-sent events reduce the load of responding to large numbers of polling requests, but at the price of requiring the Content Store to hold large numbers of persistent connections open. This can quickly become a problem, since Tomcat cannot handle more than 200 simultaneous client connections. CCI Europe therefore now ships an SSE Proxy with the Content Store. An SSE Proxy can handle up to 28,000 simultaneous client connections on behalf of the Content Store. It is possible to run many such proxies in parallel, each of which only require one connection to the Content Store, effectively removing any limitation on the total number of SSE connections that it is possible to handle.

For details of how to set up and run one or more SSE proxies for use with the Content Store, see the SSE Proxy documentation.