ProviderSession inherits from AbstractSession. In addition to the AbstractSession functionality, a ProviderSession provides the following functions to applications.

Applications can register to provide Services using either ProviderSession.RegisterService() or ProviderSession.RegisterServiceAsync(). Before registering to provide a Service an application must have established its identity.

After applications have registered a service they will start receiving subscription requests ('TopicSubscribed' message in EventType.TOPIC_STATUS) for topics which belong to the service. If the resolver has specified 'subServiceCode' for topics in 'PermissionResponse', then only providers who have activated the 'subServiceCode' will get the subscription request. Where multiple providers have registered the same service and sub-service code (if any), the provider that registered the highest priority for the sub-service code will receive subscription requests; if multiple providers have registered the same sub-service code with the same priority (or the resolver did not set a sub-service code for the subscription), the subscription request will be routed to one of the providers with the highest service priority.

A provider wishing to publish subscription data must explicitly open each topic on which they publish using ProviderSession.CreateTopics (or ProviderSession.CreateTopicsAsync). Creating a topic prepares the distribution and caching infrastructure for new data associated with the topic's resolved identifier. (Note that several different topics could resolve to the same ID.) Independent of a topic's creation status is its subscription status, i.e. whether there are subscribers ready to receive the data published. A topic that is both created and subscribed is *activated*.

There are two models for managing topic creation: broadcast and interactive. Broadcast publishers proactively call ProviderSession.CreateTopics for each topic on which they intend to publish, while interactive publishers wait to receive a 'TopicSubscribed' message (within an Event of type Event.EventType.TOPIC_STATUS before calling ProviderSession.CreateTopics in response. Topics are resolved before they are created---it is possible that multiple different topic strings will map to the same underlying topic. See below for the behavior of the SDK when the same topic is created multiple times.

After ProviderSession.CreateTopics is called, the publisher will receive a 'TopicCreated' message (within a Event.EventType.TOPIC_STATUS event), and when there is at least one subscriber to the topic the publisher will then receive a 'TopicActivated' message (also within an Event.EventType.TOPIC_STATUS event). As subscribers come and go, additional 'TopicSubscribed', 'TopicActivated', 'TopicUnsubscribed', and 'TopicDeactivated' messages may be received by the publisher. A Topic object can be retrieved from each of these messages using the ProviderSession.GetTopic method, and this object can be used for subsequent calls to EventFormatter.AppendMessage and ProviderSession.DeleteTopic. In the case that the same resolved topic is created multiple times by a publisher using different names, it is unspecified which of those names will be returned by Message.TopicName for these (or other) messages.

If a publisher no longer intends to publish data on a topic, it can call ProviderSession.DeleteTopic to free the internal caching and distribution resources associated with the topic. When a resolved topic has been deleted the same number of times that it has been created, a 'TopicDeleted' message will be delivered, preceded by 'TopicUnsubscribed' and 'TopicDeactivated' messages if the topic was still subscribed (and activated). No further messages can be published on a deleted topic.

Deregistering a service deletes all topics associated with that service.

Note that 'TopicActivated' and 'TopicDeactivated' messages are entirely redundant with 'TopicCreated', 'TopicSubscribed', 'TopicDeleted', and 'TopicUnsubscribed' messages, and are provided only for the convenience of publishers that do not maintain per-topic state.