Instant protocols can be divided into private protocols (Tencent QQ) and open protocols (GTalk) according to whether they are public or not. Private IM protocols need to be designed and built from scratch, which is extremely costly in terms of time and financial resources. While open protocols.

  • It has been researched and verified by the industry for a long time, and is guaranteed in many aspects such as security, completeness and fault tolerance.
  • Due to its open nature, the industry has a lot of excellent open source IM Server and IM Client, directly based on these open source components for development, you can quickly build a high-quality Chat base service in a relatively short period of time.
  • Open protocols are generally highly scalable and can be extended and modified to adapt to special application scenarios and needs.

Mainstream IM protocols are.

  • XMPP(Extensible Messaging and Presence Protocol)
  • SIMPLE(session initiation protocol for instant messaging and presence leveraging extensions)
  • IMPP(Instant Messaging and Presence Protocol).

IMPP

IMPP mainly defines the necessary protocols and data formats to build an instant messaging system with spatial reception and publishing capabilities. So far, this organization has published three draft RFCs, but there are two main ones: one for the site space and instant messaging model (RFC 2778); and the other for the instant messaging/space protocol requirement conditions (RFC 2779). RFC 2778 is an informative draft that defines the rationale for all PRESENCE and IM services. RFC2779 defines the minimum requirement conditions for IMPP. In addition, this draft defines some terms regarding the PRESENCE service, such as the commands to run, the format of the messages, and how the PRESENCE server notifies the client of changes in the state of the PRESENCE.

SIMPLE

SIMPLE plans to use SIP, a protocol developed for terminals in the IETF, to send presence messages, and SIP is generally considered to be used in establishing voice calls that, once connected, rely on a protocol such as Real Time Protocol (RTP) to actually send the voice. SIMPLE was defined as a way to establish an IM process. SIMPLE gained additional credence in the summer of 2002, and both Microsoft and IBM are currently working on implementing the protocol in their instant messaging systems. The SIMPLE team is committed to process mode operation, which will improve operational efficiency, enable SIP-based mechanisms for conferencing and three-way telephone conversation control, and also take into account the ability to achieve compatibility and improve performance with many new features offered in the future. With the process mode, SIMPLE uses SIP to create a process once and then uses SDP (Process Description Protocol) to actually transfer IM data.

XMPP

XMPP is an Extensible Markup Language (XML) based protocol that is used for instant messaging (IM) as well as online site probing. This protocol may eventually allow Internet users to send instant messages to anyone else on the Internet, even if their operating system and browser are different. It inherits the flexibility to evolve in an XML environment. As a result, XMPP-based applications are super scalable. XMPP can be extended to handle user needs by sending extended messages and to build applications such as content distribution systems and address-based services on top of XMPP. Moreover, XMPP includes a server-side software protocol that enables it to talk to another server, making it easier for developers to build client applications or add functionality to a patchwork system.

There are many more mainstream IM protocols available today, see Comparison of instant messaging protocols, which contains many new IM protocols. In particular, some of them with recent release dates are more suitable for the current wireless scenario. Since this paper only needs to introduce XMPP, no detailed introduction will be made here.

XMPP Introduction

XMPP was formerly known as Jabber, a network instant messaging protocol produced by an open-source organization. The Jabber Software Foundation, established in 2001, was renamed the XMPP Standards Foundation in 2007.

XMPP was originally tailored for instant messaging, but because XML Stanza itself is an XML element, the flexible development of XML-based features that make XMPP applicable to other aspects have been approved by the IETF. XMPP, together with IMPP, PRIM, and SIP, are known as the four mainstream IM protocols.

  • Instant Messaging and Presence Protocol (IMPP)
  • Presence and Instant Messaging Protocol (PRIM)
  • Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIP)
  • Extensible Message Presence Protocol (XMPP)

The XMPP and SIP protocols are architectures that help implement the specifications described in the IMPP protocol. However, it is no longer used.

Of these four protocols, XMPP is the most flexible, and is an XML-based protocol that inherits the flexibility to evolve in an XML environment. Therefore, XMPP-based applications are super scalable. XMPP can be extended to handle user needs by sending extended messages and building applications such as content distribution systems and address-based services on top of XMPP. Moreover, XMPP includes a server-side software protocol that enables it to talk to another, making it easier for developers to build client applications or add functionality to a paired system.

XMPP system features

  • XMPP protocol is open, developed by the JSF open source community organization. the XMPP protocol does not belong to any organization or individual, but belongs to the whole community, which fundamentally ensures its openness.
  • XMPP protocol has good scalability. In XMPP, instant messages and presence information are XML-based structured messages that are exchanged between communicating entities in the form of XML Stanza. XMPP acts as a common transport layer for XML structured data by embedding presence and context-sensitive information into XML structured data so that the data is delivered with great efficiency to the most appropriate resources with great efficiency. XML-based applications are built with good semantic integrity and scalability.
  • The XMPP protocol is based on a Client/Server architecture, but the XMPP protocol itself has no such limitations. The network architecture is very similar to email, but does not incorporate any specific network architecture and is very broad in scope.
  • XMPP is very resilient. XMPP can be used for instant messaging applications as well as network management, content contribution, collaboration tools, file sharing, gaming, remote system monitoring, and more.
  • XMPP uses TLS (Transport Layer Security) protocol as the encryption method for communication channels in both Client-to-Server and Server-to-Server communications to ensure secure communication. Any XMPP server can be independent of the public XMPP network (e.g., in an internal corporate network), and the use of technologies such as SASL and TLS enhances the security of communications. As shown in the figure below.

XMPP is widely used, and there are many large-scale application cases in China and abroad. Basically, except for chat protocols privatized by commercial companies, XMPP has become the de facto standard IM protocol.

XMPP-based solutions have a large number of Server-side, Client-side, and class library implementations that can quickly build applications to meet business needs. XMPP’s decentralized design has inherent scale-out scalability and also supports server-2-server XMPP’s decentralized design is inherently scalable and supports server-2-server communication, allowing connection to other XMPP servers for cross-domain chatting of accounts. In summary, XMPP is the most complete and scalable of the above protocols, with the widest range of applications and the most component support. Therefore, Chat Service chooses XMPP as the IM protocol for Chat Service.

XMPP architecture

The basic network architecture of XMPP consists of three elements: client, server, and gateway, as shown in the following diagram.

  • Server: undertakes client information recording, connection management and routing of messages.
  • Gateway: Takes on the interconnection of heterogeneous instant messaging systems, including (SMS, MSN, ICQ, etc.).

The Jabber Identifier (JID) is the account number used by the user to log in, which usually looks like an email address, e.g. someone@example.com, with the first half being the user name and the second half being the XMPP server domain name, with the two fields separated by the @ symbol.

Suppose Lei Li (LiLei@A.com) wants to talk to Mei-Mei Han (HanMeimei@B.net), and both of their accounts are on the servers A.com and B.net, respectively. When Lei Li sends a message, the process is as follows.

  • Lei Li’s XMPP client transmits his message to the com XMPP server.
  • The com XMPP server opens a connection to the net XMPP server.
  • The net XMPP server transmits the message to Han Mei Mei, and if he is not currently online, stores the message to be sent when he comes online.

Lei Li and Mei Han’s XMPP servers are provided by two different operators, and it is very convenient for them to communicate with each other without the need to have an account on the other server or to be a member of the other operator.

XMPP is a typical C/S architecture, rather than a P2P client-to-client architecture like most instant messaging software, meaning that in most cases when two clients communicate, their messages are passed through the server (there are exceptions, such as when two clients transfer files). The main reason for adopting this architecture is to simplify the client side by putting most of the work on the server side, so that the work on the client side is simpler and, when features are added, most of it is done on the server side. the framework structure of the XMPP service is shown in the figure below. three roles are defined in XMPP, XMPP client, XMPP server, and gateway. Communication can occur in both directions between any two of these three. The server takes on both client information logging, connection management, and routing of messages. The gateway takes on the interconnection with heterogeneous instant messaging systems, which can include SMS (text messaging), MSN, ICQ, etc. The basic network form is that a single client connects to a single server via TCP/IP and then transmits XML on top, working on the principle that

  • Node connects to the server
  • The server authenticates it using a certificate in the local directory system
  • The node specifies the destination address and lets the server inform the destination status
  • Servers find, connect and authenticate each other
  • Nodes interact with each other

XMPP Client

One of the design criteria for XMPP systems is that they must support simple clients. In fact, the XMPP system architecture has only a few restrictions on clients. The features that an XMPP client must support are.

  • communicating with the XMPP server via TCP sockets
  • Parsing organized XML message packets
  • Understanding message data types

XMPP shifts the complexity from the client to the server side. XMPP clients communicate with the server via XML on port 5222 of the TCP socket, without the need for direct communication between clients.

The basic XMPP client must implement the following standard protocols (XEP-0211).

  • RFC3920 Core Protocol Core
  • RFC3921 Instant Messaging and Presence ProtocolInstant Messaging and Presence
  • XEP-0030 Service Discovery Service Discovery
  • XEP-0115 Entity Capabilities

XMPP server

The XMPP server follows two main laws.

  • Listening for client connections and communicating directly with client applications
  • Communicate with other XMPP servers

XMPP open source servers are generally designed to be modular, consisting of various different code packages that handle Session management, communication between users and servers, communication between servers, DNS (Domain Name System) conversion, storage of users’ personal information and friend lists, retention of information received by users when they go offline, user registration authentication of user’s identity and authority, filtering information and system records according to user’s request, etc. In addition, the server can be extended with additional services, such as complete security policies, allowing connection of server components or client selection, gateways to other messaging systems.

The basic XMPP server must implement the following standard protocols

  • RFC3920 Core Protocol Core
  • RFC3921 Instant Messaging and Presence ProtocolInstant Messaging and Presence
  • XEP-0030 Service Discovery Service Discovery

XMPP Gateway

You may wonder why a gateway is needed here. In 1996, Mirabilis launched ICQ, the world’s first instant messaging system, and in less than 10 years, IM became one of the most popular applications, with MSN, Gtalk, Yahoo Instant Messenger, AIM, Adium, Pidgin and other software springing up, but there was no unified standard between these services. XMPP is designed to achieve interoperability of the whole timely communication service protocols, making IM the third largest service on the Internet after WEB and Email.

The outstanding feature of XMPP is that it can exchange information and user online status with other instant messaging systems. Because of the different protocols, the exchange of information between XMPP and other systems must be achieved through protocol conversion. Several major instant messaging protocols are not publicly available at present, so the XMPP server itself does not implement conversion to other protocols, but its architecture allows the implementation of conversion. The server that implements this special feature is called a gateway in the XMPP architecture. Currently, XMPP implements protocol conversions with AIM, ICQ, IRC, MSN Massager, RSS0.9, and Yahoo Massager. Thanks to the gateway, the XMPP architecture is in fact compatible with all other instant messaging networks, which undoubtedly makes XMPP much more flexible and scalable.

XMPP’s Protocols

Previously, IM-related commands were sent either in binary form (e.g. QQ) or as plain text commands with spaces and parameters plus line feeds (e.g. MSN). The logic of XMPP’s instant messaging commands is similar to that of the past, except that the protocol format has been changed to plain text in XML format. This not only makes it easier to parse, but also easier to read, facilitating development and error checking. The core part of XMPP is a stream protocol that sends XML in pieces over the network. This stream protocol is the basis for the delivery of XMPP’s instant messaging instructions, and is a very important network infrastructure protocol that can be further exploited. So it can be said that XMPP uses TCP to pass XML streams.

In fact, XMPP is a data transfer protocol very similar to the http protocol, and its process is just like the “unpacking->packing” process, the user only needs to understand the type it accepts, and understand the type it returns, then you can make good use of xmpp for data communication.

XML Streaming Transport Protocol

The definition of XMPP’s core XML Streaming Protocol allows XMPP to be on a more standardized platform than previous network communication protocols. XMPP’s instant messaging extensions are based on the IETF’s previous abstraction of instant messaging, and are as complete and advanced as other widely used instant messaging protocols, such as AIM and QQ. The official documentation for XMPP is RFC 392.

A client starts a session with an XMPP server by opening a long TCP connection and then negotiating a stream with the server. Once you and your server have established an XML stream, you and your server can exchange three special XML fragments over the stream, which are called XML stanzas. are the most meaningful basic units in XML, and once you have established an XML stream, you can send countless sections through the stream.

  • During client-to-server communication, the server must allow the client to share a TCP connection to transfer XML stanzas, both from the client to the server and from the server to the client.
  • During server-to-server communication, the server must use one TCP connection to send XML stanzas to the other side, and another TCP connection (initialized by the other side) to accept XML stanzas from the other side, for a total of two TCP connections.

An example of what a so-called XML stream looks like?

  • Client: <?xml version='1.0′? ><stream:stream to='example_com' xmlns='jabber:client' xmlns:stream='http _etherx_jabber_org/streams' version='1.0′>
  • Server: <?xml version='1.0′? ><stream:stream from='example_com' id='someid' xmlns='jabber:client ' xmlns:stream='http_etherx_jabber_org/streams' version='1.0′>
  • …other communications…
  • Client: <message from='juliet_example_com' to='romeo_example_net' xml:lang= 'en'>
  • Client: <body>Art thou not Romeo, and a Montague?</body>
  • Client: </message>
  • Server: <message from='romeo_example_net' to='juliet_example_com' xml:lang= 'en'>
  • Server: <body>Neither, fair saint, if either thee dislike.</body>
  • Server: </message>
  • Client: </stream:stream>
  • Server: </stream:stream>

In document terms, all the XML text sent by the client or server is concatenated together, from <stream> to </stream>, to form a complete XML document. One of the stream tags is the so-called XML Stream. The XML elements like <message>...</message> in between <stream> and </stream> are the so-called XML Stanza (XML stanza). The intermediate communication process is the client sending XML Stanzas, one after the other. The server sends XML Stanza to the client based on the information sent by the client and the logic of the program. But this process is not one question and answer, and at any time it is possible to send a message from one side to the other. The final stage of communication is </stream> closing the stream and closing the TCP/IP connection.

XMPP address format

Since xmpp communication is really on the network, each xmpp entity needs an address, called a JabberID (JID). A legitimate JID consists of a set of aligned elements, including a domain identifier, a node identifier, and a resource identifier. node@domain/resource is the structure most commonly used to identify an instant messaging user, the server to which the user, the server to which the user is connected, and the resource to which the user is connected. The length of each legal part of a JID cannot exceed 1023 bytes.

  • A domain name is a primary ID and is the only required element in a JID. (A pure domain name is also a legal JID). It usually represents the gateway or “master” server of the network, to which other entities connect to perform xml forwarding and data management functions. However, the entity referenced by a domain name identifier is not always a server, but may also be a server subdomain address.
  • A node name is an optional second ID that is placed before the domain name and separated by the symbol “@”. It usually indicates an entity that requests and uses a network service from a server or gateway (such as a client), but may of course indicate other entities (such as a room in a chat room).
  • The resource name is an optional third ID that is placed after the domain name and separated by a “/”. The resource name can be followed or followed by node@domain. It usually indicates a specific session connection, or an object attached to an entity related to a node ID entity.

XMPP Message Format

Two basic concepts are defined in RFC 3920 XMPP Core, XML Stream and XML Stanza. XML Stream is a container for data exchange between two nodes, which defines the top-level XML node; XML Stanza defines the specific semantic units of entity messages, and 3 top-level messages are defined in XMPP: Message, Presence and IQ.

<Message>

Message is a basic push message method that does not require a response. It is mainly used in applications like IM, groupChat, alert and notification.

The main attributes are as follows.

  • type attribute, which has 5 main types.
    • normal: This message type is delivered immediately or stored offline by the server and is handled by the client as a separate message outside of any chat or group chat conversation. This type is the default value. Similar to email, the main feature is that it does not require a response.
    • chat: The chat message type is usually sent as a burst message within a relatively short period of time during a “chat session”. The instant messaging client displays these messages in a one-to-one conversation interface. It is similar to the live chat with friends in qq, and the main feature is real-time communication.
    • groupchat: The XMPP server typically routes messages of route type groupchat to a specialized component or module that has multiple chat rooms, and this component generates an outbound message to everyone in the room. Similar to a group chat in a chat room.
    • headline: headline messages are usually not stored offline because they are temporary. In addition, XMPP servers often pass headline type messages to all online devices associated with the account (at least with a non-negative priority value). Used to send alerts and notifications.
    • error: messages of type error are sent out in response to a previously sent message to indicate that an error was sent in connection with the previous message (the recipient was not present, the message could not be sent at this time, etc.). If an error is made in sending a message, the entity that finds the error will use this category to notify the sender that an error has occurred.
  • to attribute: identifies the recipient of the message.
  • from attribute: The name or label of the sender. To prevent address leaks, this address is usually filled in by the sender’s server, not the sender.
  • payload: This element contains the information to be submitted to the target user. For example, body, subject, thread

The message structure is as follows.

1
2
3

<message from="abc@jabber.org/contact" to="def@jabber.org/contact" type="chat">
    <body>hello</body>
</message>

Adding a status to a chat without knowing the person you are chatting with can lead to the misconception that the other person is offline or doesn’t want to talk to people, which inevitably makes people lose something in their minds. For example, if you are chatting with your girlfriend and you ask, “Honey, what did you do today?”, your girlfriend is excited and she has a lot to tell you, but because she takes too long to type you think she doesn’t love you …. Well, such a chat is not very sadistic …. Then, there is still a way, you need to get the chat status notice in your IM system, define the chat status notice [XEP-0085]

Chat status.

  • Starting: The person started a conversation, but you are not yet involved
  • Active: you are participating in a conversation, you are not currently organizing your messages, but are following
  • Composing: person is organizing a message
  • Paused: started organizing a message, but for some reason stopped organizing it
  • Inactive: Not participating in this conversation for some time
  • Gone: participation in this conversation has ended

Example.

1
2
3
4

<message from="abc@jabber.org/contact" to="def@jabber.org/contact" type="chat">
    <body>hello</body>
    <starting xmlns="http://jabber.org/protocol/chatstates"/>
</message>

<Presence>

presence is used to indicate the user’s state, e.g., online, away, dnd (do not disturb), etc. When changing its own state, a Presence element is inserted in the stream’s context to indicate its own state. To receive a PRESENCE message, you must go through an authorization process called PRESENCE subscription.

Attributes.

  • type attribute, not required. There are the following categories
    • subscribe: subscribe to the state of other users
    • probe: request to get the status of other users
    • unavailable: unavailable, offline (offline) state
  • to attribute: identifies the recipient of the message.
  • from attribute: the name or marker of the sender.
  • load (payload).
  • show.
    • chat: in chat
    • away: temporarily away
    • xa: eXtend Away, leave for a long time
    • dnd: do not disturb
  • status: freely formatted, readable text. Also called rich presence or extended presence, often used to indicate the user’s current mood, activity, songs they are listening to, videos they are watching, chat rooms they are in, web pages they are visiting, games they are playing, and so on.
  • priority: range -128 to 127. high priority resource can accept messages sent to bare JID, low priority resource cannot. A resource with a negative priority cannot receive messages sent to bare JID.

The message structure is as follows.

1
2
3

<presence from="abc@jabber.org/contact" to="def@jabber.org/contact">
    <status>online</status>
</presence>

<IQ>(Info / Query)

A request/response mechanism where from one entity from sends a request, another entity accepts the request and responds. For example, the client inserts an element in the context of the stream, requests a list of its friends from the Server, and the Server returns one, containing the result of the request.

The main attribute is type. the entity sending the IQ section must always receive a reply (usually generated by the destination recipient or the recipient’s server). Requests and replies are tracked by using the id attribute, which is generated by the requesting entity and is included in the responding entity.

  • Get : Request entity information, such as a request to register an account (similar to HTTP GET).
  • Set : The requesting entity provides some information or makes a request (similar to HTTP POST or PUT).
  • Result : The responding entity returns the result of a get operation (e.g. an entity must provide information to register an account) or acknowledges a set request (similar to an HTTP 200 status code).
  • Error: The responding entity or an intermediate entity, such as an XMPP server, notifies the requesting entity that it cannot process the get or set request (e.g., because the request is not in the correct format, the requesting entity is not authorized to perform the operation, etc.). The numeric error codes used earlier in HTTP have been replaced by XML elements with extensible error conditions.

The message structure is as follows.

1

<iq from="abc@jabber.org/contact" id=“id11” type=“result”></iq>

This brings us to one of XMPP’s much touted drawbacks: 70% of network traffic is consumed at the XMPP protocol layer due to the use of XML. Based on this WhatsApp has improved the XMPP protocol on this basis.

Components of the XMPP protocol

Major XMPP protocol templates and XMPP extensions that are widely used today.

  • RFC 3920 XMPP: Core. Defines the network architecture of applications in the framework of the XMPP protocol, introduces XML Stream (XML stream) and XML Stanza (XML section), and specifies the XML tags used by the XMPP protocol in the communication process. The use of XML tags is fundamentally necessary for the openness and extensibility of the protocol. In addition, in terms of the security of communication, the TLS secure transport mechanism and SASL authentication mechanism are introduced into the kernel to provide a seamless connection with XMPP, laying the foundation for the security and reliability of the protocol. core document also specifies the definition and handling of errors, the specification of the use of XML, the definition of JID (Jabber Identifier), the naming conventions, and so on. So this is a document that all XMPP protocol-based applications must support.
  • RFC 3921: After a user successfully logs in to the server, he/she publishes updates to his/her online buddy management, sends live chat messages, and other services. RFC 3921 also defines blocking policies, which are defined as multiple blocking methods. It can be said that RFC3921 is a full complement to RFC3920. Combined, the two documents form a basic instant messaging protocol platform on which a wide variety of applications can be developed.
  • XEP-0030 Service Search. A powerful protocol for determining the characteristics supported by other entities in an XMPP network.
  • XEP-0115 Entity Performance. a customization of XEP-0030 through instant attendance that allows real-time changes to the alternate advertisement feature.
  • XEP-0045 Multi-Person Chat. A set of protocols defining participation and management of multi-user chat rooms, similar to Internet’s Relay Chat, with a high level of security.
  • XEP-0096 File Transfer. Defines the transfer of files from one XMPP entity to another.
  • XEP-0124 HTTP Binding. Binds XMPP to HTTP instead of TCP and is mainly used for devices that are not able to persistently maintain a TCP connection to the server.
  • XEP-0166 Jingle. specifies the overall architecture for negotiating multimedia communications.
  • XEP-0167 Jingle Audio Content Description Format. defines the voice transport process from one XMPP entity to another.
  • XEP-0176 Jingle ICE (Interactive Connectivity Establishment) Transport. ICE transport mechanism, the document solves the problem of how to allow entities protected by firewalls or NAT (Network Address Translation) to establish connections. XEP-0177 Jingle ICE (Interactive Connectivity Establishment) Transport.
  • XEP-0177 Jingle Raw UDP Transport. pure UDP transport mechanism, which describes how to establish connections without firewalls and on the same network.
  • XEP-0180 Jingle Video Content Description Format. defines the process of transferring video from one XMPP entity to another.
  • XEP-0181 Jingle DTMF (Dual Tone Multi-Frequency).
  • XEP-0183 Jingle Telepathy Transport Method.

XMPP Server selection

XMPP Server solution

XMPP Server has numerous implementation options.

Among them, the more mature and widely used are ejabberd, jabberd 2.x, Openfire, Tigase.

  • Jabberd 2.x was implemented in C. However, there were problems with database transaction abuse, memory leaks, inconsistent non-blocking design, and most importantly, the server had not been maintained for a long time; therefore, chesspark switched to ejabberd after three years of using jabberd 2.x. Not coincidentally, org also switched to ejabberd in In 2010, org also phased out Jabberd and switched to using Openfire and Tigase are both JAVA-based solutions. But Openfire single-computer concurrency is very limited, the cluster solution is immature, the code is old and lack of timely updates, so it is not suitable for use in production environments. Tigase, however, is a complex cluster solution with limited single-node capacity.

From the programming language point of view, the mainstream XMPP Server is mainly JAVA and Erlang. JAVA has the advantage of a complete class library and easy recruitment. Relatively elegant clustering scheme and higher concurrency performance. In the absence of language bias, ejabberd is generally used in the early stages of development, e.g. MiChat.

From various features supported by XMPP Server, ejabberd is the server with the best support and most comprehensive implementation of the XMPP protocol.

From the open source protocol, Tigase uses the AGPL open source protocol, so as long as there are code modifications, the code must be open source. Openfire uses the Apache open source protocol, and the code can be closed source after modification. ejabberd uses the GPL v2 open source protocol, so if the service is only provided on the server side without secondary distribution of the code, the code can also be “closed source” after modification. closed source".

Taking all these factors into account, Chat Service uses ejabberd as the initial XMPP Server.

ejabberd

  • ejabberd is a free and open source instant messaging server written in the Erlang/OTP language
  • ejabberd is cross-platform, distributed, fault-tolerant, and based on open standards for real-time communication systems
  • ejabberd is designed to be rock-solid and is a feature-rich XMPP server
  • ejabberd is suitable for both small and very large deployments, regardless of whether they require scalability

Key Features.

  • Cross-platform: ejabberd can run on Microsoft Windows and Unix-derived systems such as Linux, FreeBSD and
  • Distributed: You can run ejabberd on a cluster of machines, all serving the same or a number of Jabbe domains. When you need more capacity, you can simply add an inexpensive node to your cluster. So, you don’t need to buy an expensive high-end machine to support tens of thousands of concurrent users.
  • Fault tolerance: You can deploy an ejabberd cluster so that all the necessary information for a functioning service will be replicated to all nodes. This means that if one of the nodes crashes, the others will continue to run without interruption. Alternatively, nodes can be added or replaced ‘without downtime’.
  • Easy to manage: ejabberd is built on open source so you don’t need to install an external service database, an external web server, and so on because everything is already included and available out of the box. Other administrative benefits include:
    • Extensive documentation
    • Easy installer for Linux, Mac OS X, and Windows systems
    • Web management
    • Shared roster groups
    • Command line management tools
    • Externally-integratable authentication mechanism
    • Ability to send anonymous messages
  • Internationalization: ejabberd leads internationalization. Ideal for globalization. Related features include:
    • Translation into 25 languages
    • Support for IDNA
  • Open standards: ejabberd is an open source Jabber server that fully supports XMPP standards.
    • Fully compatible
    • XML-based protocols
    • Many supported protocols

Additional features.

  • Modularity

    • Fit in only the modules you want
    • Extend in your own custom modules

  • Security

    • SASL support for c2s and s2s connections
    • STARTTLS support for s2s connections
    • Web management with secure access via HTTPS

  • Database

    • Rapidly deployable internal database (Mnesia)
    • Native MySQL support
    • Native PostgreSQL support
    • ODBC data storage support
    • Support for Microsoft SQL Server

  • Validation

    • Internal validation
    • PAM, LDAP
    • External validation scripts

  • Other

    • Virtual hosting support
    • XML stream compression (XEP-0138)
    • Statistics (XEP-0039)
    • Support for IPv6 c2s and s2s connections
    • Multi-user chat module with support for clustering and HTML logging
    • User directory based on user vCards
    • Publish-Subscribe component with support for PubSub-based personal events
    • Support for web client: HTTP Polling and HTTP Binding (BOSH) services
    • IRC Gateway
    • Component support: interfaces with external networks after installing specific gateways, such as AIM, ICQ and

    OpenFire

To understand Openfire, we must first understand the XMPP protocol, because Openfire is written in Java, based on the XMPP protocol, open source real-time collaboration server. openfire has cross-platform capabilities, Openfire and the client is using the C/S architecture, a server is responsible for providing services to clients connected to it. Openfire clients are spark, pidgin, Miranda IM, iChat, etc. If users develop their own clients, they can use the open source Client-side API-Smack, which follows the GPL. If developers need to add new services, they can develop their own plug-ins and install them to the server to provide services, such as finding contacts service is provided in the form of plug-ins.

OpenFire is developed in Java based on the XMPP (Jabber) protocol , open source real-time collaboration (RTC) server . smack is written in Java XMPP client code base , is the core of spark , open source community always has a lot of interesting things , these three together is a complete XMPP IM implementation .

  • OpenFire – server-side
  • Spark - the client side
  • Smack - an implementation of the XMPP transport protocol

All three are based on the Java language implementation, where XMPP is a protocol, the protocol is required to implement, Smack plays such a role.

OpenFire is a server-side implementation of IM based on the XMPP protocol. Although when two users are connected, they can send messages in a peer-to-peer manner, the user still needs to connect to the server to get some connection information and communication information, so the server side is a must.

Spark provides a basic implementation on the client side and proposes a good plug-in architecture, which can’t be a boon for developers. I highly recommend implementing your newly added functionality based on the plug-in approach, rather than changing its source code, which will benefit your project architecture and minimize the impact of the original project.

Smack is a Java implementation of the XMPP protocol that provides a set of extensible APIs, but there are times when you have to use your own custom XML file content sent to implement your own functionality

The relationship between the three.

From the above diagram, we can see that both Client side and Server side can be extended by way of plug-ins, and Smack is the medium for both to pass data.

Openfire Server Capacity

A single Openfire server should have no problem supporting more than 3K capacity, but more needs to be tested. The open source version does not support Clustering, but we can use Openfire + Connection Manager to expand the server capacity. Some users have tested that an Openfire server with 8G memory can support up to 300,000 users if the Connection Manager is configured. We can calculate the approximate capacity of Openfire + Connection Manager server. Assuming one Connection Manager and Openfire each occupy 20 connections, each Openfire server can support 5000 connections and each Connection Manager can support 3000 connections, if we configure 4 Connection Managers, then we can calculate If we configure 4 Connection Managers, we can calculate the capacity of Openfire server: 15000-420+43000-420 = 16840. We did a test, running Openfire 3.7.0 on a virtual machine, we can login 2W users at the same time, after adding Clustering, only 1W6.

Reference links.