Subscriptions running mechanism

Subscriptions running mechanism

Peter Saint-Andre

Jabber, Inc.

1 Introduction

Subscriptions is the most complex part of Jabber. The server and the client have a lot of work to ensure that the user receives or sends the correct subscription request, accepts or rejects the requested request, cancels the subscription, delete the flown book, and so on. This document focuses on how the Subscription works in the two-layer structure: (1) XML protocol requires responding to a specific action; (2) User: XML file return status includes Jabber User, such as subscribers, etc.) and contacts (If you are subscribed).

2, Subscription status

There are four Subscription status:

1, None - Jabber users and contacts do not subscribe to each other's Presence

2, to - Jabber users are subscribed by the contact's Presence, but the contact is not subscribed by the Jabber user.

3, from - contact accepts subscription from Jabber users, but the contact is not subscribed by the Jabber user's Presence (such result is "invisible" in the Jabber user in the contact's roster).

4, Both - Jabber users and contacts are subscribed to each other's Presence.

When the Jabber user adds the contact in his roster (usually by sending a subscriptiong request for the contact), there is still a fifth state in the name, that is, the Jabber user and the contacts don't even know the existence of the other party (at least through The flower name of each user is displayed). However, we have no name in this state. From this document, I define this state as the initial state.

3, subscribe to a contact

As mentioned above, subscriptions, and the status of Subscriptions and their associated flown books are quite complex. So here I will make an extremely detailed description of a Jabber user with a contact so that you can figure out a Jabber user subscribes to a contact's Presence, resulting that the Jabber user has a subcription to the contact. What happened during this process. We will send a subscription request from Jabber users to a subscription request.

1. In order to let the contacts visible on the Jabber user's roster, Jabber user client

(1) Send a package, its Jabber: IQ: Roster name space contains a type = 'set';

(2) In the case of success, a package is received from the server, and its type = 'result' is received.

(3) Receive a "Roster Push" from the server to generate a new ROSTER entry, and its subscription status is set to "NONE":

Jabber User Sends:

JID = 'Contact @ Host'

Name = 'contact' />

Jabber User Receives:

TYPE = 'result'

From = 'jabberuser @ Host / Work'

TO = 'jabberuser @ host / work' />

JID = 'Contact @ Host'

Subscription = 'None'

Name = 'contact' />

2, Jabber users' clients are connected to the package of type = 'subscribe''s to contact:

Jabber User Sends:

To = 'Contact @ Host'

TYPE = 'Subscribe'>

i would like to add you to my roster.

3. The Jabber User Client receives "roster push" "Roster Push" that contains the second 'None' subscription state containing the contact to be stator status; this is included in its flower name book entries in its flower name bookcase entry contains an Ask = 'subscribe' attribute :

Jabber User Receives:

JID = 'Contact @ Host'

Subscription = 'None'

Name = 'contact'

ask = 'Subscribe' />

4. Once the Jabber user client sends Type = 'Subscribe''s package, the package is sent to the contact (we assume that the contact is online):

Contact Receives:

To = 'Contact @ Host'

TYPE = 'Subscribe'

From = 'jabberuser @ Host'>

i would like to add you to my roster.

5, the next step in the next step is to decide whether to accept the subscription request. Here we assume "Happy Path", that is, the contact accepts subscription, which contact's Jabber client:

(1) Send a type = 'subscribed' package to Jabber users

(2) Receive a "ROSTER PUSH" from the server contains entries for Jabber users, where the subscription status is set to "from":

Contact Sends:

Contact Receives:

JID = 'jabberuser @ host'

Subscription = 'from' />

6. The result of the contact accepting the subscription request is: Jabber user client receives

(1) A "Roster Push" from the from the contact from the contact (2) from the server, which contains an updated entry to update the contact's subscription To "TO";

Jabber User Receives:

To = 'jabberuser @ host'

TYPE = 'Subscribed'

From = 'contact@ host' />

JID = 'Contact @ Host'

Subscription = 'to'

Name = 'contact' />

Now Jabber users have subscribed to contacts. The flown booklets of each User.xml will be as follows:

Jabber User's Roster:

JID = 'Contact @ Host'

Subscription = 'to'

Name = 'contact' />

Contact's Roster:

JID = 'jabberuser @ host'

Subscription = 'from' />

(Note: If the Jabber user sends a subscription request to the contact, the Jabber user's JabBer server will "swallow" the request, and no longer sends it to the contact.)

4, get a subscription from a contact

As we see in front, we need a two-way subscription between Jabber users and contacts. At the end of this process, we will study the situation of Jabber users to subscribe with each other.

5. Create a mutually subscribed Subscription

To create a mutually subscription (such as a subscription = 'Both'), you must send a subscription request to the JABBER user, and the Jabber user must accept the request. Let us look at what XML has passed back, and it is clear what happened, and what happened to each person's roster file.

1. First, the contact sends a subscription request to the Jabber user:

Contact Sends:

i would like to add you to my roster.

2, the contact client receives a "roster push" from the server, which contains the Jabber user is still 'from' Subscription status, but at the same time, the Subscription on 'to' Subscription is from the Ask = 'Subscribe' in the flown booklet. The attribute is generated:

Contact Receives:

JID = 'jabberuser @ host'

Subscription = 'from'

Name = 'jabberuser'

ask = 'Subscribe' />

One result of this behavior is that the status of the roster files of the contact and Jabber users are as follows:

Contact's Roster:

JID = 'jabberuser @ host'

Subscription = 'from'

Name = 'jabberuser'

ask = 'Subscribe' />

Jabber User's Roster:

JID = 'Contact @ Host'

Subscription = 'to'

Name = 'contact'

Subscribe = 'I Would Like to add you to my roster.' />

3. Once the contact client sends a package containing type = 'subscribe', the package will be sent directly to the Jabber user (we assume that Jabber User online):

Jabber User Receives:

To = 'jabberuser @ host'

TYPE = 'Subscribe'

From = 'contact @ host'>

i would like to add you to my roster.

4. Jabber User's next step is to decide whether to accept subscription requests. Here we assume "Happy Path", that is, the contact accepts subscription, so that Jabbyonghu's Jabber client:

(1) Send a package for the of the for the contact.

(2) Receive a "Roster Push" from the server contains the entry of the contact, where the subscription status is set to "BOTH":

Jabber User Sends:

Jabber User Receives:

JID = 'Contact @ Host'

Subscription = 'Both' />

5. The result of the JABBER user accepts the subscription request is: Contact clients receive

(1) a package from the type = 'subscribed' from Jabber users.

(2) A "ROSTER PUSH" from the server, which contains an updated entry to update the subScription of the Jabber user as "to";

Contact Receives:

To = 'Contact @ Host'

TYPE = 'Subscribed'

From = 'jabberuser @ host' />

JID = 'jabberuser @ host'subscription =' Both '

Name = 'jabberuser' />

One result of this behavior is that the status of the roster files of the contact and Jabber users are as follows:

Contact's Roster:

JID = 'jabberuser @ host'

Subscription = 'Both'

Name = 'jabberuser' />

Jabber User's Roster:

JID = 'Contact @ Host'

Subscription = 'Both'

Name = 'contact' />

Jabber users and contacts now have an Subscription-of Subscription, and their subscription type is "BOTH". (Note: If the Jabber user sends a subscription request to the contact, or the contact sends a subscription request to the Jabber user, the sender's JabBer server will "swallow" the request, and no longer send it to the contact.)

6, cancel a subscription

Once you subscribe to someone's Presence in Jabber, in some cases you may need to cancel the subscribe of the other party.

Although the XML you sent is different, the Jabber user and the contact's roster files behave differently depending on the status of their flown book files when the subscription package is coming.

6.1, Example # 1: Subscription Type 'to'

In our first example, we assume that the Jabber user has a subscription of the contact, and the contact does not come to the Jabber user's subscription. In this example, the status of each person's roster file is as follows:

Jabber User's Roster:

JID = 'Contact @ Host'

Subscription = 'to'

Name = 'contact' />

Contact's Roster:

JID = 'jabberuser @ host'

Subscription = 'from'

Name = 'jabberuser' />

1. In order to cancel the subscribe of the contact, Jabber users send the following XML:

Jabber User Sends:

2. Send the result of the Presence package, the Jabber user client receives a "Roster Push" from the Jabber server, which contains 'ask' attributes to cancel the subscription, indicating that the subscription is to be determined:

Jabber User Receives:

JID = 'Contact @ Host'

Subscription = 'to'

Name = 'contact'

ask = 'unsubscribe' />

3. The existing Jabber server feature will automatically reply to the PRESENCE package for the unsubscribe (Note: This means that the contact will be processed without online). This causes Jabber users to receive the following XML: Jabber User Receives:

TYPE = 'unsubscribed'

To = 'jabberuser @ host'

From = 'contact @ host'>

autoreply

4, Jabber users will also receive a "roster push" from the Jabber server, and its contact subscription is again set to 'None':

JID = 'Contact @ Host'

Subscription = 'None'

Name = 'contact' />

5. Finally make the flown and jabber user's roster files as follows:

Jabber User's Roster:

JID = 'Contact @ Host'

Subscription = 'None'

Name = 'contact' />

Contact's Roster:

NO for Jabber User

6.2, Example # 2: Subscription Type 'Both'

Second example, we assume that Jabber users have a subscription of the contact, and the contact also has a subscription to the Jabber user. In this example, the status of the flown books of each person is as follows:

Jabber User's Roster:

JID = 'Contact @ Host'

Subscription = 'Both'

Name = 'contact' />

Contact's Roster:

JID = 'jabberuser @ host'

Subscription = 'Both'

Name = 'jabberuser' />

1. In order to cancel the subscription from the contact's Presence, the Jabber user sends the following XML:

Jabber User Sends:

2. After sending this Presence package, the Jabber user client immediately receives a "ROSTER PUSH" from the Jabber server, where 'ask' is set to unsubscribe to indicate this cancel subscription to pending:

JID = 'Contact @ Host'

Subscription = 'Both'

Name = 'contact'

ask = 'unsubscribe' />

3, the existing Jabber system will automatically replace the contact reply to a unsubscribe's Presence package (note: whether the contact is online, for the Subscription request is or not processed, the result is the same, although "Roster Push" There is a little different when requested by the request). Jabber users will receive the following XML: Jabber User Receives:

TYPE = 'unsubscribed'

To = 'jabberuser @ host'

From = 'contact @ host'>

autoreply

4, Jabber users will receive a "roster push" from the Jabber server, which change the contact to 'from': (Contact Continue to subscribe to the Jabber user's Presence)

JID = 'Contact @ Host'

Subscription = 'from'

Name = 'contact' />

5, the contact will receive a "ROSTER PUSH" from the Jabber server, and its subscription change the Jabber user to 'to' (from this Jabber user no longer subscribes to the contact's Presence)

JID = 'jabberuser @ host'

Subscription = 'to'

Name = 'jabberuser' />

6. Finally, the status of the flower album file of the contact with Jabber users is as follows:

Jabber User's Roster:

JID = 'Contact @ Host'

Subscription = 'from'

Name = 'contact' />

Contact's Roster:

JID = 'jabberuser @ host'

Subscription = 'to'

Name = 'jabberuser' />

7, delete a friend entry

In addition to canceling the subscription from someone's Presence, you can also remove the other party's corresponding entry from your roster. You can send a package that contains special subscriptions to 'Remove'. Typically, send a delete request to start a process from your roster to delete someone, while the server performs the details of the cancel subscription. Here is a workflow ...

7.1, Example # 1: Subscription Type 'to'

We first example, we will assume that the Jabber user has a subscription of the contact, but the contact does not come to the Jabber user's subscription. In this example, the state of the flown files of each person is as follows:

Jabber User's Roster:

JID = 'Contact @ Host'

Subscription = 'to'

Name = 'contact' />

Contact's Roster:

Subscription = 'from'

Name = 'jabberuser' />

1. The first step is that the Jabber user sends a cancellation request:

Jabber User Sends:

XMLns = 'jabber: iq: roster'>

JID = 'Contact @ Host'

Subscription = 'remove' />

2. After sending a cancellation request, the Jabber user receives:

(1) A "roster push" for the contact

(2) A type = 'result' package, indicating the request:

Jabber User Receives:

TYPE = 'result'

From = 'jabberuser @ Host / Work'

TO = 'jabberuser @ host / work' />

3, in addition, the contact is received:

(1) a 'unsubscribe' Presence package

(2) A "ROSTER PUSH", indicating the Subscription of the Jabber User's Booklet Estate Subscription as 'None':

Contact Receives:

Type = 'unsubscribe'

To = 'Contact @ Host'

From = 'jabberuser @ host' />

JID = 'jabberuser @ host'

Subscription = 'None'

Name = 'jabberuser' />

7.2, Example # 2: Subscription Type 'Both'

The second example, we assume that the Jabber user has a subscription of the contact, and the contact also has a subscription to the Jabber user. In this example, the state of the flown books of each person is as follows:

Jabber User's Roster:

JID = 'Contact @ Host'

Subscription = 'Both'

Name = 'contact' />

Contact's Roster:

JID = 'jabberuser @ host'

Subscription = 'Both'

Name = 'jabberuser' />

1. The first step is that the Jabber user sends a delete request:

Jabber User Sends:

XMLns = 'Jabber: IQ: roster'>

Subscription = 'remove' />

2. After sending the request, the Jabber user receives:

(1) A "Roster Push" package for the contact

(2) A type = 'result''s package begins to request:

Jabber User Receives:

TYPE = 'result'

From = 'jabberuser @ Host / Work'

TO = 'jabberuser @ host / work' />

3, at the same time, the contact is received:

(1) A type of type is 'unsubscribe' PRESENCE package

(2) A "roster push" package, change the Subscription of the Jabber user's flown book entry, 'to'

(3) A type is 'unsubscribed''s Presence package

(4) A "ROST PUSH" package, adapting the Subscription of the Jabber User's Booklet Estate for "None";

Contact Receives:

Type = 'unsubscribe'

To = 'Contact @ Host'

From = 'jabberuser @ host' />

JID = 'jabberuser @ host'

Subscription = 'to'

Name = 'jabberuser' />

TYPE = 'unsubscribed'

To = 'Contact @ Host'

From = 'jabberuser @ host' />

JID = 'jabberuser @ host'

Subscription = 'None'

Name = 'jabberuser' />

8. Client development precautions

From the above discussion, it must be clear that the detailed XML fragment does not necessarily refer to the same thing, nor does it necessarily have the same meaning - its meaning determines the context of Subscription in the actual situation and the status of the flown booklet. The developer of the Jabber client needs to keep this in mind when writing code. In general, it is best not to modify the client side about the speech list, which is based on the external XML of the server. In most cases, you only need to wait "Roster Push" and make your client change according to it. 9, reference

This article quoted the following materials:

l Jabber Programmers Guide (http://docs.jabber.org/jpg/)

l jabber protocol overview (http://docs.jabber.org/general/html/protocol.html)

l jabber protocol-standard (http://docs.jabber.org/proto/)

note

1. If the contact is not online, the following XML saves to the contact's roster file:

JID = 'jabberuser @ host'

Subscription = 'None'

Subscribe = 'I Would Like to add you to my roster.' />

When the contact is logged in next time, the server will prompt the 'subScribe' attribute and generate a Type = 'subscribe' package from the Jabber user, send it to the contact.

2. If the contact rejects the subscription request, the contact's client sends the following XML to the Jabber user:

Jabber users receive this presence package, and receive "Roster Push" from the server.

To = 'jabberuser @ host'

TYPE = 'unsubscribed'

From = 'contact@ host' />

JID = 'Contact @ Host'

Subscription = 'None'

Name = 'contact' />

After this operation, the roster state of Jabber users and contacts is as follows:

Jabber User's Roster:

JID = 'Contact @ Host'

Subscription = 'None'

Name = 'contact' />

Contact's Roster:

NO for Jabber User

You will definitely want to know why it is deleted from the Jabber user's romantic list (the roster, which is returned, I called it "initial state", and the second is to save a TYPE in the roster. "None" subscription. A problem, but the existing Jabber system mechanism I want to say is to run in this way. (Note If the Jabber user sends a subscription request to the contact, its performance is exactly the same as the contact not online, except for the Jabber user client does not have to get the initial roster from the server.) 3, if Jabber users are online, the following XML save the roster file of Jabber users:

JID = 'Contact @ Host'

Subscription = 'to'

Subscribe = 'I Would Like to add you to my roster.' />

When the next Jabber user logs in, the server notes the 'subscribe' attribute, then generates a package from the contact to the Jabber user.

4. If the Jabber user rejects the subscription request, the Jabber user's client sends the following XML to the contact:

The contact will also receive a "roster push" from the server, changing the Jabber user's subscription status as "from":

To = 'Contact @ Host'

TYPE = 'unsubscribed'

From = 'jabberuser @ host' />

JID = 'jabberuser @ host'

Subscription = 'from'

Name = 'jabberuser' />

As a result, the status of the roster of the contact and Jabber users is as follows:

Contact's Roster:

JID = 'jabberuser @ host'

Subscription = 'from'

Name = 'jabberuser' />

Jabber User's Roster:

JID = 'Contact @ Host'

Subscription = 'to'

Name = 'contact' />