The FeedSync algorithm specifies the synchronization of data between the two endpoints by using a publication and subscription model. Endpoint A publishes synchronization metadata to which endpoint B can subscribe and vice versa. This model has two features that are significantly different from popular feed-based interaction protocols, such as ATOM.

• The communication defined between the two endpoints is a peer-to-peer communication. ATOM and RSS have interactions that are client-server based.
  
• The FeedSync specification does not describe how endpoints discover each other. In the ATOM and RSS models, servers are easily discoverable and don't need to keep track of clients.
  

The Resource Model topic describes the synchronizable resources that support exchanging FeedSync metadata. However, to handle the issues raised by peer-to-peer communication, the Live Framework implementation of FeedSync is a client-server model. The process of synchronization is as follows:

1. The FeedSync client subscribes to the feed that the FeedSync server published.
   
2. If the FeedSync client makes a change, the client updates the feed with changes on its end by using the MERGE operation as specified by the FeedSync specification.
   
3. The FeedSync client posts the updated feed to the FeedSync server.
   
4. When the server receives the feed, it performs the MERGE operation to update the feed.
   

In other words, if an application needs to synchronize information between endpoint A and endpoint B, the peer-to-peer implementation is as follows:

1. Endpoint A performs an HTTP GET from endpoint B
   
2. Endpoint B performs an HTTP GET from endpoint A.
   

Instead, in the client-server implementation, the following occurs:

1. Endpoint A (the client) performs an HTTP GET from endpoint B (the server).
   
2. Endpoint A does an HTTP POST to endpoint B.
   

The client (endpoint A) has the responsibility to perform the operation in the correct order to synchronize its information with the server, as opposed to making both endpoints responsible for such action. At any given point in time, the server now contains the latest information.

Although there are advantages to a peer-to-peer model, the client-server model can easily be implemented as a hub-and-spoke model such that there is a single server with the master version of data with which multiple clients can synchronize data. With a peer-to-peer model, each endpoint needs information about all of the other endpoints and also needs to establish a trusted relationship with them in order to synchronize data.

The FeedSync client updates its local state by doing a GET operation on the feed from the server and by performing the MERGE operation that is specified in the FeedSync specification. When the local data on the client changes, the client needs to synchronize the server with this information. It synchronizes the server by performing a POST of the updated feed to the FeedSync server. This feed should contain the latest updated entries and the newly created entries on top of the feed that was received from the server. All such entries will also contain the FeedSync metadata.

The FeedSync server supports receiving a POST containing FeedSync metadata as a FeedSync endpoint. Upon reception of such a request, it should perform the MERGE operation as specified by the FeedSync spec. It should also support receiving a GET of the FeedSync feed, in which it returns the feed that is the result of MERGE operation.

The Live Framework contains a number of implementations of the FeedSync specification, from the basic XML and HTTP implementation that supports any programming environment that can produce and consume XML over HTTP, to the abstract object model presented by the .NET Framework Toolkit for Live Framework. For more information about the implementation of the FeedSync specification, see the following topics:

• Using the .NET AtomPub Library
  
• Using the .NET Libraries
  
• Using the JavaScript Library
  

The basic XML and HTTP implementation of the FeedSync specification uses data feeds that contain not only data entries, but the following two additional feeds:

• /SyncEntries – This feed contains all the entries for the feed, which are the same entries as /DataEntries, as well as FeedSync metadata. A FeedSync client uses this feed rather than the /DataEntries feed to synchronize data. The /SyncEntries feed does not support HTTP operations on individual entries within the feed. It only supports GET and POST operations of the FeedSync feed.
  
• /MediaStagingArea – This feed contains media entries until they are moved to /MediaResources feed. To create a new member entry in a FeedSync client, the following steps occur:
  

1. The client creates a new entry in the local feed.
   
2. The client does a POST of that feed to the /SyncEntries feed. The new member entry is not ATOM compliant because the server has yet to assign an ID.
   
3. The server creates the necessary ATOM entry in the /DataEntries feed and performs the MERGE operation.
   

To create a new media entry in a FeedSync client, the following steps occur:

1. The client posts the media to /MediaStagingArea.
   
2. The server returns an ID corresponding to the media entry to the client in the form of a response header called Staged-Media-Resource-Url.
   
3. The client creates a new media link entry in the local feed in this format: <link rel="StagedMediaResource" href="ID">, where ID is the ID from the server.
   
4. The client posts this feed to the /SyncEntries feed. The POST operation on /SyncEntries must happen within eight hours of the post of the media resource to /MediaStagingArea. Otherwise, the media resource may get garbage collected.
   
5. The server creates a media resource from the ID obtained from <link rel="StagedMediaResource"> for the new media link entry and updates it with a link to the media resource.
   
6. The server performs the MERGE operation.
   

Deletion of media resources also has a special implementation, because in FeedSync, when an entry is deleted by an endpoint, the entry is marked for deletion. In the Live Framework, the server maintains a reference count for the media resources and does not delete the media resource until all the FeedSync endpoints have marked the resource for deletion.

Note:
Any entries posted in the /SyncEntries feed are also available to non-FeedSync clients at the /DataEntries feed, without the FeedSync metadata. Similarly, entries posted to the /DataEntries feed are be available through the /SyncEntries feed, without the FeedSync metadata.

Conflicts occur during synchronization when two or more updates are applied to the same data before a synchronization operation runs. The Live Operating Environment detects a conflict and does not allow a synchronization to occur. For further information about detecting and handling FeedSync conflicts, see the following topics:

• Using the .NET AtomPub Library
  
• Using the .NET Libraries
  
• Using the JavaScript Library
  

Concepts

Other Resources