XEP-0184 More and more applications for mobile devices nowadays include chat functionality and often XMPP protocol is the natural choice as it is widely supported both in form of client libraries and range of servers. However, in mobile networks, data transmission is not always reliable even when using TCP. It is sometimes desirable to guarantee that not a single message will be lost. However, the core XMPP specification doesn’t tackle this problem. This problem can be overcome with XEP-0184. It is a powerful extension which provides Message Delivery Receipts. This protocol enables a sender to ask the recipient to acknowledge receipt of a content message by returning an ‘ack’ message. MongooseIM is an Erlang-based implementation of XMPP server with focus on performance and scalability. MongooseIM offers a base platform for building messaging systems. Specifically designed for enterprise purposes, it is fault-tolerant and can utilize resources of multi-core CPUs. It provides support for WebSockets, reliable message delivery in mobile networks and in-game multi-user chats. Its modular architecture allows customizing it to cater to specific needs like in-house authentication or application-specific traffic such as VoIP signalling. Customized plugins can be easily built on top of MongooseIM. It is through XEP- 0184 plugin that Erlang Solution provides an extension to address issues of reliable message delivery in mobile networks. XEP-0184 introduces a new feature to the XMPP protocol: message delivery receipt. It allows you to be sure whether your message has been delivered to the Recipient. This feature can be extended with packet cache on the server side to ensure message delivery in mobile networks. It is cheap and easy to implement. Why use XEP- 0184? • It’s a quick and easy solution for mobile applications • Flexible configuration • The overhead is kept at minimum • Packet cache module doesn’t require any other modifications to MongooseIM THE COMMUNICATION STEPS OF XEP-0184: 1 1. Sender to Server- The sender sends the message, along with a request for a delivery receipt. 2 SENDER RECIPIENT 2. Server to Recipient-MongooseIM caches the message, sets the timer and waits for a receipt. If the message is lost, it will just execute the configured actions such as saving the packet to offline storage. 3. Recipient to Server-The server executes the chosen actions if the receipt gets lost on its way. The Recipient might possibly end up with duplicated messages. 4 ABOUT ERLANG SOLUTIONS 3 • Founded in 1999 soon after Erlang was released as open source • Only company of its kind totally focused on Erlang and Erlang community • With over 300 clients www.erlang-solutions.com 4. Server to sender- The sender receives the confirmation of the message delivery. • Headquartered in London, U.K. • Offices in Aarhus, Amsterdam, Budapest, Copenhagen, Krakow, Stockholm and Zurich