XMPP (Extensible Messaging and Presence Protocol) is an open technology that provides a way to send small pieces of information in XML format from one entity to another in real time. According to popular XMPP: The Definitive Guidebook: XMPP technology uses a decentralized client-server architecture such that client developers can concentrate on the user experience and server developers can concentrate on reliability and scalability.
By using the protocol, we can build up applications like instant messaging, group chat, voice over IP, identity service (such as OpenID & OAuth), online gaming etc.
Here are some guidelines to decide if XMPP is a good option or not:
- When communication among a distributed network of entities or servers is required.
- When channel encryption, strong authentication, and trusted identities are required.
- When information about network availability is required, i.e. presence.
Client and server communicate through port 5222 on a TCP connection. XML streams contain XMPP information. An XMPP session is opened by tag and ended with tag. All other information is located in between them. The open stream is followed by Transport Layer Security (TLS) and Simple Authentication and Security Layer (SASL) handshake. A new stream will be opened just after the SASL handshake.
We developed a chat client in Java that communicates with OpenFire (XMPP based open source server) as per below logic:
- First, the client sends an open stream packed to the server for requesting a new session. In response to that, a server sends an XML stream starting with and includes requirements of either TLS or SASL negotiation or both.
- Now if a server needs TLS negotiation when a client sends a STARTTLS to server and server sends back a message showing that the TLS is allowed. In case of failure, the server closes the TCP connection.
- If TLS is processed, then client requests a new session and server responses an XML stream indicating the needs of SASL negotiation.
- Now, client needs to choose an authentication mode available from the server to carry out SASL negotiation. Client sends a stream with the selected authorization mode. If the server accepts the authorization, it replies a stream with “success” tag.
- Immediately after SASL negotiation, client establishes a session to start the instant messaging. Server sends back an ‘iq’ stanza showing whether session has been created successfully or not. If the server failed to create a session, it will reply with the error message.
- If all steps above goes successful, then the client sends XMPP technology stanzas to the server and receives XML streams. Client sends stanzas to request information from server, and use
stanzas to change its present status. Instance message and other information can be sent via stanzas.
- If clients want to end the talk and close the XMPP session, it required to send a close stream to server.
- Finally, server will change client’s status to ‘Offline’ and close TCP connection with the client.