Android OpenFire and XMPP

<span id="Label3"></p><p><p>For the XMPP protocol, refer to: http://www.jabbercn.org</p></p><p><p><strong>What is OpenFire</strong></p></p><p><p>OpenFire is developed in java, and the open source real-time collaboration (RTC) server is based on the XMPP (Jabber) Protocol.</p></p><p><p>You can use it to easily build an efficient instant messaging server. OpenFire is easy to install and use, and is managed with the Web. A single server can support tens of thousands of concurrent Users.</p></p><p><p>Because of the open XMPP protocol, you can use various IM client software that supports the XMPP protocol to log on to the Service.</p></p><p><p><strong>XMPP</strong> <strong>(</strong> <strong>Jabber</strong> <strong>) Protocol</strong></p></p><p><p><strong>1.</strong> <strong>Introduction</strong></p></p><p><p>XMPP is an xml-based protocol that inherits the flexibility of development in an XML Environment. As a result, xmpp-based applications have super-scalable Capability. The extended XMPP can handle the User's needs by sending extended information, as well as creating applications such as content publishing systems and address-based services at the top of xmpp. furthermore, XMPP contains a software protocol for the server side that enables it to talk to another, making it easier for developers to build customer applications or add functionality to a well-equipped system.</p></p><p><p><strong>2.</strong> definition:</p></p><p><p>XMPP (extensible Messaging Field Protocol) is an Extensible Markup language (XML)-based protocol that is used for instant messaging (im) and online field probing. It facilitates quasi-immediate operation between Servers. This agreement may eventually allow Internet users to send instant messages to anyone else on the internet, even if their operating systems and browsers are Different.</p></p><p><p>Xmpp's predecessor was jabber, an open source form of organization-generated network Instant Messaging Protocol. XMPP is currently being standardized by the IETF International standards Organization. The core results of standardization are divided into two parts;</p></p><p><p>The core XML Stream Transfer Protocol</p></p><p><p>Application of instant communication extension based on XML Freeeim stream transmission</p></p><p><p>The definition of the core XML streaming protocol for XMPP enables XMPP to be on a more standardized platform than the previous network communication Protocol. With the help of Xml's easy parsing and reading features, the protocol of XMPP can be very beautiful.</p></p><p><p>The Instant Messenger extension Application section of XMPP is based on an abstract definition of instant messaging by the IETF prior to this, with other widely used instant messaging protocols such as aim,qq, which are functionally complete and perfect.</p></p><p><p>In the ietf, the IM protocol is divided into four protocols, instant Messaging and Presence protocol (Instant Messaging and presence Protocol, impp), presence and Instant Messaging protocol (presence and Instant Messaging Protocol, PRIM), Session Initiation Protocol for Instant Messaging and Presence Extensions (session initiation Protocol for Instant Messaging and Presence leveraging Extensions, simple), as well as the extensible Message Presence Protocol (XMPP). The IMPP was originally developed to create a standardized protocol, but today IMPP has evolved into a basic protocol unit that defines the core set of features that all instant messaging protocols should Support.</p></p><p><p>3. The advantages of XMPP protocol</p></p><p><p>A. The XMPP protocol is open and developed by the JSF open source community Organization. The XMPP protocol is not owned by any institution or individual, but belongs to the entire community, which fundamentally guarantees its openness.</p></p><p><p>B. The XMPP protocol has good Extensibility. In xmpp, both instant messages and presence information are xml-based structured information exchanged between communication entities in the form of an XML section (xml Stanza). XMPP plays the role of the universal Transport layer of XML structured data, which embeds presence and context-sensitive information into XML structured data, allowing the data to be delivered to the most appropriate resource with great Efficiency. The application based on XML has good semantic integrity and Extensibility.</p></p><p><p>C. Distributed network Architecture. The XMPP protocol is based on the Client/server architecture, but the XMPP protocol itself has no such limitations. The architecture of the network is very similar to e-mail, but it is not combined with any particular network architecture and is widely applicable.</p></p><p><p>D. XMPP has good Elasticity. In addition to the applications available for instant messaging, XMPP can be used in network management, content feeds, collaboration tools, file sharing, gaming, remote system monitoring, and More.</p></p><p><p>E. Security. XMPP uses the TLS (Transport Layer Security) protocol as the communication channel encryption method in Client-to-server communication, and server-to-server communication to ensure the security of Communication. Any XMPP server can be independent of the public XMPP network (for example, within an intranet), and the use of technologies such as SASL and TLS enhances communication Security. As shown in the Following:</p></p><p><p>4, the composition of the XMPP protocol</p></p><p><p>The main XMPP protocol model and Today's widely used XMPP extensions:</p></p><p><p>L RFC 3920 XMPP (new RFC6120): core. Defines the network architecture applied under the XMPP protocol framework, introduces the XML stream (xml Flow) and XML Stanza (xml section), and specifies the XML tags that the XMPP protocol uses in the communication process. The use of XML tags is fundamentally the need for openness and extensibility of protocols. In addition, in the security aspect of communication, the TLS secure transmission mechanism and the SASL authentication mechanism are introduced into the kernel, and the connection with XMPP is seamless, which lays the foundation for the security and reliability of the Protocol. The Core document also specifies the definition and handling of errors, the use of XML, the definition of JID (Jabber identifier,jabber identifiers), naming conventions, and so On. So this is a document that must be supported by all XMPP protocol-based Applications.</p></p><p><p>RFC 3921: After the user has successfully logged on to the server, publish and update their online friend management, send instant chat messages and other business. All of these businesses are done through three basic XML sections: IQ Stanza (iq section), presence Stanza (presence), message Stanza (message section). RFC3921 also defines blocking policies, which are defined as multiple blocking METHODS. It can be said that RFC3921 is the full complement of RFC3920. together, Two documents form a basic Instant Messaging protocol platform that can be used to develop a wide variety of applications.</p></p><p><p>L XEP-0030 Service Search. A powerful protocol for determining the features supported by other entities in the XMPP Network.</p></p><p><p>L XEP-0115 Solid Performance. One of XEP-0030 's customizable, instant-on-the-fly, can change the ad function in real Time.</p></p><p><p>L XEP-0045 Chat with many People. A set of protocols that define the participation and management of multi-user chat rooms, similar to the Internet relay chat, with high Security.</p></p><p><p>L XEP-0096 File Transfer. Defines a file transfer from one XMPP entity to Another.</p></p><p><p>L XEP-0124 HTTP bindings. Bind XMPP to HTTP instead of tcp, primarily for devices that do not persist with server TCP Connections.</p></p><p><p>L XEP-0166 Jingle. The whole structure of multimedia communication negotiation is Stipulated.</p></p><p><p>L XEP-0167 jingle Audio Content Description Format. Defines the voice transfer process from one XMPP entity to Another.</p></p><p><p>L XEP-0176 jingle ICE (Interactive Connectivity Establishment) Transport. Ice transport mechanism, which resolves the issue of how to make a connection to an entity that is protected by a firewall or NAT (Network Address translation).</p></p><p><p>L XEP-0177 jingle Raw UDP Transport. A pure UDP transport mechanism that describes how to establish a connection under the same network without a Firewall.</p></p><p><p>L XEP-0180 jingle Video Content Description Format. Defines the video transfer process from one XMPP entity to Another.</p></p><p><p>L XEP-0181 jingle DTMF (Dual Tone multi-frequency).</p></p><p><p>L XEP-0183 Jingle Telepathy Transport Method.</p></p><p><p>5. XMPP Protocol Network Architecture</p></p><p><p>XMPP is a typical c/s architecture, not like most instant messaging software, which uses peer-to-client architecture, which means that in most cases, when two clients are communicating, their messages are delivered through the server (with exceptions, such as when transferring files to two clients). With this architecture, the main purpose is to simplify the client, the majority of the work on the server side, so that the Client's work is relatively simple, and when the increase in functionality, most of the Server-side. The framework structure of the XMPP service is as Shown. Three roles are defined in xmpp, xmpp client, xmpp server, gateway. Communication can occur bidirectional between any two of these three. The server also assumes the client information record, connection management and information routing Function. The gateway undertakes the interconnection with the heterogeneous instant communication system, and the heterogeneous system can include SMS (sms), MSN, ICQ and so On. The basic network form is that a single client connects to a single server over TCP/IP and then transfers the XML over it, which works by:</p></p><p><p>(1) point to connect to the server;</p></p><p><p>(2) The service device uses the certificate of the local directory system to authenticate it;</p></p><p><p>(3) point to specify the destination address, let the server inform the target state;</p></p><p><p>(4) to find, Connect and authenticate each other;</p></p><p><p>(5) the interaction between points;</p></p><p><p>6. XMPP Client</p></p><p><p>One design standard for XMPP systems is the need to support simple clients. In fact, the XMPP system architecture has only a few limitations on Clients. The features that an XMPP client must support Are:</p></p><p><p>1. Communicate with the XMPP server via TCP sockets;</p></p><p><p>2. Parse well-organized XML packets;</p></p><p><p>3. Understand the message data type.</p></p><p><p>XMPP transfers complexity from the client to the server Side. This makes it very easy for clients to write, and it is also easier to update system Functionality. The XMPP client communicates with the server through XML on port 5222 of the TCP socket without requiring direct communication between the Clients.</p></p><p><p>The basic XMPP client must implement the following standard protocol (XEP-0211):</p></p><p><p>RFC3920 Core Protocols</p></p><p><p>RFC3921 Instant Messaging and Presence agreement instant Messaging and presence</p></p><p><p>XEP-0030 Services Discovery Service Discovery</p></p><p><p>XEP-0115 Entity capacity entities capabilities</p></p><p><p>7. XMPP Server</p></p><p><p>The XMPP server follows two main rules:</p></p><p><p>1, listen to the client connection, and directly communicate with the client application;</p></p><p><p>2, communication with other XMPP servers;</p></p><p><p>XMPP open source servers are generally designed to be modular and consist of different code packages that handle session management, communication between users and servers, communication between servers, DNS (Domain Name System) transformations, storing User's personal information and friends list, Keep the information that the user receives at the downline, the user registers, the User's identity and authority authentication, filter the information and the system record according to the User's Request. In addition, servers can be extended through additional services, such as full security policies, allowing connection of server components or client selection, gateways to other messaging Systems.</p></p><p><p>The basic XMPP server must implement the following standard protocols</p></p><p><p>RFC3920 Core Protocols</p></p><p><p>RFC3921 Instant Messaging and Presence agreement instant Messaging and presence</p></p><p><p>XEP-0030 Services Discovery Service Discovery</p></p><p><p>8. XMPP Gateway</p></p><p><p>XMPP is characterized by the ability to exchange information and user online conditions with other instant Messaging Systems. Because of the different protocols, XMPP and other system exchange information must be implemented through the conversion of the protocol, there are currently several mainstream instant communication protocols are not disclosed, so the XMPP server itself does not implement and other protocol conversion, but its architecture allows the implementation of the Transformation. The server that implements this particular feature is called the Gateway in the XMPP architecture. currently, XMPP implements protocol conversions with aim, ICQ, IRC, MSN massager, RSS0.9, and Yahoo massager. Because of the presence of gateways, the XMPP architecture is virtually compatible with all other instant communication networks, which undoubtedly greatly improves the flexibility and scalability of xmpp.</p></p><p><p>9. XMPP Address format</p></p><p><p>An entity is called a contact in the XMPP network structure, it has a unique identifier Jabber identifier (JID), which is the entity address, which is used to represent a jabber user, but can also represent other content, such as a chat room. A valid Jid consists of a series of elements:</p></p><p><p>(1) name (domain identifier);</p></p><p><p>(2) Point (node identifier);</p></p><p><p>(3) Source (resource identifier).</p></p><p><p>Its format is [email Protected]/resource,[email protected], similar to the email address format. Domain is used to indicate a different device or location, this is optional, for example a in Server1 registered a user, the user name is doom, then a jid is [email protected], when sending a message, specify [email protected] yes, resource can not be specified, but a in the login to this server, fl jid may be [email protected], Exodus (if A with Exodus software login), may also be [email protected]/psi ( If a is logged in with the PSI software). Resources are used only to identify the location or device belonging to the user, and a user can connect to the same XMPP server with multiple resources at the same time.</p></p><p><p>10. XMPP Message Format</p></p><p><p>3 top-level XML elements are defined in Xmpp: Message, presence, IQ, described below for these three elements.</p></p><p><p><strong><Message></strong></p></p><p><p>Used to send information between two Jabber Users. The JSM (jabber session Manager) is responsible for all messages, regardless of the status of the target User. If the user JSM online immediately, Otherwise the JSM will be Stored.</p></p><p><p>To: identifies the recipient of the Message.</p></p><p><p>From: refers to the Sender's name or identifier (id)</p></p><p><p>Text: This element contains the information to be submitted to the target User.</p></p><p><p>The structure is as follows:</p></p><p><p><message to= ' [email protected]/contact ' type = ' chat ' ></p></p><p><p><body> hello, are you busy </body></p></p><p><p></message></p></p><p><p><strong><Presence></strong></p></p><p><p>Used to indicate the User's status, such as online, away, DND (do not disturb), etc. When a user goes offline or changes his or her state, a presence element is inserted in the context of the stream to indicate its State. The structure is as follows:</p></p><p><p><presence></p></p><p><p>from = ' Lily @ jabber.com/contact '</p></p><p><p>to = ' Yaoman @ jabber.com/contact '</p></p><p><p><status> Online </status></p></p><p><p></presence></p></p><p><p>The <presence> element can take several values:</p></p><p><p>Probe: used to send a special request to the Accept message method</p></p><p><p>Subscribe: automatically sends presence information to the sender when the recipient State Changes.</p></p><p><p><strong>< IQ ></strong></p></p><p><p>A request/response mechanism from an entity that sends a request, another entity accepts the request, and RESPONDS. For example, the client inserts an element into the context of the stream, asks the server for its friend list, and the server returns one, which is the result of the Request.</p></p><p><p><iq > The primary attribute is Type. Including:</p></p><p><p>Get: gets the current domain Value.</p></p><p><p>Set: Sets or replaces the value of a get query.</p></p><p><p>Result: the description succeeded in responding to the previous Query.</p></p><p><p>Error: errors occurred in query and Response.</p></p><p><p>The structure is as follows:</p></p><p><p><iq from = ' Lily @ jabber.com/contact ' id= ' 1364564666 ' type= ' result ' ></p></p>XMPP Communication Protocol<p><p><strong>first,</strong> <strong>Stream</strong></p></p><pre><pre><!--#################### communication content using compression technology, and communication protocol #######################--</pre></pre><pre><pre><stream:stream xmlns:stream= "http://etherx.jabber.org/streams"</pre></pre><pre><pre> xmlns= "jabber:client" from= "127.0.0.1" id= "e38900bc" xml:lang= "en"</pre></pre><pre><pre> version= "1.0" ></pre></pre><pre><pre><!--</pre></pre><pre><pre>xmlns indicates communication client</pre></pre><pre><pre>From client address (source)</pre></pre><pre><pre>Id</pre></pre><pre><pre>Lang Communication language</pre></pre><pre><pre>- </pre></pre><pre><pre><stream:features></pre></pre><pre><pre> <!--start the TLS protocol [tls] channel encryption method--</pre></pre><pre><pre> <starttls xmlns= "urn:ietf:params:xml:ns:xmpp-tls" ></starttls></pre></pre><pre><pre> <!--encryption technology, Security certificate--</pre></pre><pre><pre> <mechanisms xmlns= "urn:ietf:params:xml:ns:xmpp-sasl" ></pre></pre><pre><pre> <mechanism>DIGEST-MD5</mechanism></pre></pre><pre><pre> <mechanism>PLAIN</mechanism></pre></pre><pre><pre> <mechanism>ANONYMOUS</mechanism></pre></pre><pre><pre> <mechanism>CRAM-MD5</mechanism></pre></pre><pre><pre> </mechanisms></pre></pre><pre><pre> <!--with Compression technology--</pre></pre><pre><pre> <compression xmlns= "http://jabber.org/features/compress" ></pre></pre><pre><pre> <method>zlib</method></pre></pre><pre><pre> </compression></pre></pre><pre><pre> <!--permissions--</pre></pre><pre><pre> <auth xmlns= "http://jabber.org/features/iq-auth"/></pre></pre><pre><pre> <!--registration--</pre></pre><pre><pre> <register xmlns= "http://jabber.org/features/iq-register"/></pre></pre><pre><pre></stream:features></pre></pre><p><p>About TSL reference: http://www.jabbercn.org/RFC3920</p></p><p><p><strong>1</strong> <strong>,</strong> <strong>TSL</strong> <strong>the protocol follows these rules:</strong></p></p><p><p>a, an initialization entity that complies with this agreement must (must) include a ' version ' attribute in the header information of the initialization stream and set the value to "1.0".</p></p><p><p>B, If the TLS handshake occurs between two servers, the communication cannot continue (must Not) unless the server claims that the DNS hostname has been resolved.</p></p><p><p>C, when a receiving entity that complies with this agreement receives an initialization stream (its header information contains a ' version ' attribute and the value is set to "1.0"), it must be sent (must) after the header information (which contains the version tag) of the reply stream is sent (in) <starttls/> Element (the namespace is ' Urn:ietf:params:xml:ns:xmpp-tls ') and other stream features it Supports.</p></p><p><p>D, if the initialization entity chooses to use the TLS,TLS handshake must be completed before the SASL handshake, which is used to help secure the authentication information sent when the SASL handshake is secured, and to provide a certificate for the SASL external mechanism before the TLS handshake, if necessary.</p></p><p><p>E, during the TLS handshake, an entity cannot (must not) send any whitespace symbols as elements in the root element of the stream (any whitespace in the following TLS example is simply for readability); This prohibition is used to help ensure security layer byte Accuracy.</p></p><p><p>F, the receiving entity must (must) start the TLS negotiation immediately after the send <proceed/> element's close symbol ">". The initialization entity must (must) begin the TLS negotiation immediately after receiving the close symbol ">" of the <proceed/> element from the receiving Entity.</p></p><p><p>G, the initialization entity must (must) verify the certificate presented by the receiving entity, and for the certificate verification process see certificate Validation (chapter 14th, Section ii).</p></p><p><p>H, The certificate must (must) check the host name provided by the initializing entity (such as a user), rather than the hostname resolved by the DNS system, for example, If the user specifies a hostname "example.com" and a DNS SRV [srv] query returns " Im.example.com ", The certificate must (must) check for" example.com ". if the jid of any kind of XMPP entity (such as a client or server) appears in a certificate, it must (must) behave as a UTF8 string inside an alias entity, exist in the Subjectaltname. How to use the [asn.1] object identifier "id-on-xmppaddr" is defined in the first section of chapter fifth of this Article.</p></p><p><p>I, if the TLS handshake succeeds, the receiving entity must (must) discard any unreliable information obtained from the initialized entity before TLS takes effect</p></p><p><p>J. if the TLS handshake succeeds, the initialization entity must (must) discard any unreliable information obtained from the receiving entity before TLS takes effect</p></p><p><p>K, if the TLS handshake succeeds, the receiving entity cannot (must Not) provide an STARTTLS extension to the initialization entity by providing additional streaming characteristics when the stream restarts</p></p><p><p>L, if the TLS handshake succeeds, the initialization entity must (must) continue with the SASL handshake</p></p><p><p>M, if the TLS handshake fails, the receiving entity must (must) terminate the XML stream and the corresponding TCP Connection.</p></p><p><p>N, on the mechanisms required (must) support, refer to mandatory-to-implement Technologies (chapter 14th, Section seventh).</p></p><p><p><strong>2</strong> <strong>, when an initialization entity is used</strong> <strong>TLS</strong> <strong>protect the flow between one and the receiving entity, with the following steps</strong> <strong>:</strong></p></p><p><p>A. Initializing an entity opens a TCP connection, sending an Open XML stream header information (its ' Version ' property is set to "1.0") to the receiving entity to initialize a Stream.</p></p><p><p>B. the receiving entity opens a TCP connection, sending an XML stream header information (whose ' Version ' property is set to "1.0") to initialize the entity as a reply.</p></p><p><p>C. the receiving entity proposes a STARTTLS scope (including other supported stream Characteristics) to the initialization entity, and if TLS is required for and receiving entity interaction, It should (should) include child elements in the <starttls/> element <required/></p></p><p><p>D. Initialize the entity issue the STARTTLS command (for example, a <starttls/> element that conforms to the ' Urn:ietf:params:xml:ns:xmpp-tls ' namespace) to inform the receiving entity that it wants to start a TLS handshake to protect the Stream.</p></p><p><p>E. the receiving entity must (must) answer with the <proceed/> element or <failure/> element in the ' Urn:ietf:params:xml:ns:xmpp-tls ' namespace. If it fails, the receiving entity must (must) terminate the XML stream and the corresponding TCP Connection. If you proceed, the receiving entity must (must) attempt to complete the TLS handshake over the TCP connection and cannot send any additional XML data (must Not) until the TLS handshake is Complete.</p></p><p><p>F. Initialize the entity and the receiving entity to attempt to complete the TLS handshake. (to conform to the [TLS] Specification)</p></p><p><p>G. If the TLS handshake is unsuccessful, the receiving entity must (must) terminate the TCP Connection. If the TLS handshake succeeds, the initialization entity must (must) send an Open XML stream header information to the receiving entity to initialize a new stream (sending a close tag first </stream> is unnecessary because the receiving entity and the initialization entity must (must) Ensure that the original stream is closed after the TLS handshake SUCCEEDS.</p></p><p><p>H. After receiving the new stream header information from the initialized entity, the receiving entity must (must) send a new XML stream header information to the initialization entity as an answer, which should contain the available attributes but not the STATRTTLS Attribute.</p></p><p><p>Android OpenFire and XMPP</p></p></span>