XMPP-scalable message and attendance information protocols (Overview), xmpp-Attendance

XMPP-scalable message and attendance information protocols (Overview), xmpp-Attendance
Overview

The extensible message and attendance Information Protocol (XMPP) mainly uses XML streams to exchange structured information in near real time on any two network terminals, XMPP provides a universal and scalable framework for exchanging XML data for quasi-Real-Time Messages and attendance information and request-response services.

General Architecture

XMPP does not specify any specific network structure, but it is usually implemented using the client-server architecture. The client uses the XMPP method to access the server through TCP, and the server also uses the TCP method to communicate.

1. A simple XMPP architecture composed of the same domain name server and client

A client with a unique name communicates with another client with a unique name through the relevant server. Each client executes the Protocol form of the client, and the server provides the routing function in the form.

2. Complex XMPP architecture including Gateway

For different domains (XMPP domains, SMS domains, and SMTP domains), the gateway can translate XMPP into an external (non-XMPP) message system, and translate the returned message into XMPP. As a scalable protocol, XMPP is an ideal hub protocol for providing unified connectivity between different endpoints protocols. XMPP gateway allows you to terminate a specified client-to-Server session and initiate a new session to the target endpoint protocol (and perform necessary protocol conversion at the same time ).

Address Space Overview

The address of an XMPP object is called JID. A valid JID contains an optional node, a domain name, and an optional resource name. a jid is used as the network communication ID and is unique.

XMPPJID * jid = [node "@"] domain ["/" resource];

The length of each valid part (node name, domain name, and Resource Name) of a JID cannot exceed 1023 bytes. That is, the overall length (including '@' and '/') cannot exceed 3071 bytes.

[Optional node] domain name [Optional resources]

Domain Name: Primary ID. The entity referenced by a domain name identity is not always a server. It may also be a subdomain address of a server.

Optional node: The Second ID, which usually indicates an entity (such as a client) requesting and using network services from the server or gateway ), of course, it can also represent other entities (such as a room in a multi-user Chat System)

Optional resources: usually indicates a specific session, connection (such as a device or location), or an object attached to a node ID entity (such as a participant in a multi-user chat room ), also known as the third ID

XML Stream and XML section Overview

XML Stream and XML section make it possible to asynchronously exchange low-load structured information between entities

XML Stream:

An XML Stream is a container that contains XML elements exchanged between two entities over the network. An XML stream starts with an XML open tag <stream> (including appropriate attributes and namespace declarations), and ends with an XML close tag </stream>. Throughout the life cycle of a stream, the entity that initializes it can send a large number of XML elements through the stream for stream handshaking (TLS handshake or SASL handshake) or XML section (here mainly refers to elements that match the default namespace, including <message/>, <presence/>, or <iq/> elements)

An "Initial stream" is a handshake between an initial entity (usually a client or server) and a Receiving Entity (usually a server). From the perspective of the Receiving Entity, it is the "session" of the initial object ". the initialization stream allows one-way communication from the initialization object to the receiving entity. To enable the Receiving Entity to exchange information with the initial entity, the receiving entity must initiate a reverse handshake (Response stream ).

XML section:

An XML section is a discrete semantic unit in the structured information sent by an object to another object through XML. Any XML section starts from an open tag (such as <presence>) at the lower level of an XML Stream and closes the tag (such as </presence>) (here, the XML section is limited to <message/>, <presence/>, and <iq/> elements)

Session between the client and the server:

1. The client sends an open tag <Stream> to the server to initialize the Stream (you can also send a text declaration before this to the XML version and the supported Character Set)

2. The server replies an XML stream to the client (you can also send a text declaration before this)

3. The client completes the SASL handshake

4. The client sends the closing tag </stream> to the server (or the server sends the tag to the client)

5. The client and server completely terminate the connection (usually a TCP connection)

Communication type

The real-time message passing system using XMPP contains three communication categories:

• Message transmission, where data is transmitted between Parties; <message>
• Online status, which allows users to broadcast their online status and availability. <presence>
• Information/query request, which allows an XMPP object to initiate a request and receive a response from another object. <Iq>

 <stream>     <presence>        <show/>     </presence>     <message>        <body/>     </message>     <iq>        <query/>     </iq> </stream>

Bind to TCP

Although many non-essential connections use XML streams to bind [TCP] connections (two entities can be interconnected through other mechanisms, such as [HTTP] connection polling ), during the communication between the client and the server, the server must allow the client to share a TCP connection to transmit the XML section, including transmitting data from the client to the server and from the server to the client. During the communication between servers, the server must use a TCP connection to send an XML section to the other party, and the other TCP connection (initialized by the other party) receives the XML section of the other party. There are two TCP connections in total.

Stream Security

When an XML Stream starts to shake hands, although there may be a common mechanism to ensure two-way security, it "initializes the stream" (for example, the stream from the initialization object to the receiving object) it must be separated from the "response stream" (for example, the stream sent from the receiving object to the initialization object. When a stream is verified, the object should not try to send an XML section through the stream; even if it does, the object of the other party cannot accept these XML sections, A <not-authorized/> stream error message should be returned and the XML Stream of both parties on the current TCP connection should be terminated. Note, this is only for the XML section (the <message/>, <presence/>, and <iq/> elements contained in the default namespace ), instead of the streams Used For TLS handshake and SASL handshake.

Stream attributes

• To: It appears in the XML stream from the initialization object to the acceptance object. The value is the acceptance object JID. If it appears in the response stream, the initialization object should be ignored.
• From: appears in the header of the XML stream that receives an object and sends it to the initialization object. The value is the JID of the initialization object. If it appears in the initialization object, the acceptance object should be ignored.
• Id: it is used to receive the unique ID created by the accepted object in the header sent to the initialized object XML Stream. It also serves as the session ID between the initialized object and the accepted object, if it appears in the initialization stream, the entity accepted should be ignored.
• Xml: lang: it is included in the initialization stream that is initialized to receive objects. It is used to specify the default language used for the readable XML characters transmitted in the stream. If this value does not exist, the default value is applied, if this value exists, the accepted entity cannot modify this value.
• Version: supported versions

Stream Error

The root element of a stream can (MAY) contain a <error/> sub-element, with the stream namespace prefix as its prefix.

<stream:error>     <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>    [optional text]     <text xmlns='urn:ietf:params:xml:ns:xmpp-streams' xml:lang='langcode'>        descriptive text     </text></stream:error>

Rules

The following rules apply to stream-level errors:

• It assumes that all stream-level errors are irrecoverable. Therefore, if an error occurs at the stream level, the entity that discovers this error MUST (MUST) Send a stream error message to another entity, send a close tag </stream> and terminate the TCP connection of the stream.

• If this error occurs when the stream is set at the beginning, the receiving entity MUST (MUST) still send an open tag <stream>, the stream element contains a <error/> sub-element, sends a close tag </stream>, and ends the corresponding TCP connection. In this case, if the initialization object provides an unknown host name in the 'to' attribute, the server SHOULD (shoshould) before terminating, first, provide a server-authenticated host name in the 'From' attribute of the stream header information.

Stream error condition definition

The following stream-level error conditions are defined:

• <Bad-format/> -- the object has sent XML but cannot be processed. This error can be replaced by more XML-related errors, such as <bad-namespace-prefix/>, <invalid-xml/>, <restricted-xml/>, <unsupported-encoding/>, and <xml-not-well-formed/>, although more specific errors are preferred.

• <Bad-namespace-prefix/> -- The namespace prefix sent by the object is not supported, or a namespace prefix is not sent to an element that requires a certain prefix.

• <Conflict/> -- the server is disabling the stream activated for this entity because a new stream conflicting with an existing stream has been initialized.

• <Connection-timeout/> -- the object has not used this stream for a long time to generate any communication traffic (which can be configured by a local service policy ).

• <Host-gone/> -- initialize the host specified by the 'to' attribute value provided by the object in the stream header information. It is no longer provided by this server.

• <Host-unknown/> -- the value of the 'to' attribute provided by the initialization object in the stream header information is inconsistent with the host name provided by the server.

• <Improper-addressing/> -- a section transmitted between two servers lacks the 'to' or 'from' attribute (or this attribute has no value ).

• <Internal-server-error/> -- the server configuration error or other undefined internal errors make the server unable to provide stream service.

• <Invalid-from/> -- The JID or host name address provided in the 'From' attribute does not match the authenticated JID or the server cannot pass SASL (or call back) negotiate a valid domain name, or the client and server cannot use it for authentication and resource binding.

• <Invalid-id/> -- the stream ID or callback ID is invalid or inconsistent with the previously provided ID.

• <Invalid-namespace/> -- stream namespace is different from "http://etherx.jabber.org/streams" or the callback namespace is different from "jabber: server: dialback.

• <Invalid-xml/> -- the entity sends an invalid XML to the server performing the verification through the stream.

• <Not-authorized/> -- the entity attempts to send data before the stream is verified or is not allowed to perform an action related to stream negotiation, the recipient entity cannot process the deprecated section before sending the error message.

• <Policy-violation/> -- the entity violates some local service policies. The server can specify the policy in the <text/> element or the error condition (element) defined by the application.

• <Remote-connection-failed/> -- the server cannot properly connect to the remote entity used for verification or authorization.

• <Resource-constraint/> -- the server lacks the necessary system resources for stream service.

• <Restricted-xml/> -- the entity attempts to send restricted XML features, such as a comment, processing instruction, DTD, object reference, or reserved characters.

• <See-other-host/> -- the server will not provide services to the initialization entity but redirect it to another host; the server should specify the server name or IP address in the XML character data of the <see-other-host/> element (it must (must) be a valid domain name ID ).

• <System-shutdown/> -- the server is shutting down and all activated streams are being shut down.

• <Undefined-condition/> -- the error condition is not in the list of error conditions defined in this article. This error condition should be used only for the "application-defined condition" element.

• <Unsupported-encoding/> -- the initialization object encodes a stream in an unsupported encoding mode on the server.

• <Unsupported-stanza-type/> -- initialize the object to send a first-level sub-element of a stream, but not supported by the server.

• <Unsupported-version/> -- the version specified by the 'version' attribute value specified by the initialization object in the stream header is not supported by the server; the server can specify a supported version number in the <text/> element.

• <Xml-not-well-formed/> -- the initialization object sends an nonstandard XML (refer to [XML])

References:

Http://www.ibm.com/developerworks/cn/xml/x-xmppintro/index.html

Http://www.ibm.com/developerworks/cn/xml/tutorials/x-realtimeXMPPtut/index.html