Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

XMPP Academy #1

1,633 views

Published on

This is the slide deck for ProcessOne first live XMPP Academy.

Here are the questions covered:

1. ejabberd SaaS architecture questions
- What is the best way to archive user messages if we do not want to sync data from user device?
- Why does ejabberd SaaS not use async mechanisms for archiving messages to customer back-end server?
- Mobile XMPP support: Explain standby, push and detached modes.

2. XMPP / ejabberd questions
- How does ejabberd internally store messages which are not yet delivered?
- How are privacy lists managed in ejabberd?
- What is on the ejabberd roadmap ? OAuth !

Published in: Technology
  • Be the first to comment

XMPP Academy #1

  1. 1. Academy #1 28th september 2015 Mickaël Rémond, @mickael Video recording: https://youtu.be/-dqQfCpw98E
  2. 2. Questions ejabberd SaaS architecture questions • What is the best way to archive user messages if we do not want to sync data from user device? • Why does ejabberd SaaS not use async mechanisms for archiving messages to customer back-end server? • Mobile XMPP support: Explain standby, push and detached modes XMPP / ejabberd questions • How does ejabberd internally store messages which are not yet delivered? • How are privacy lists managed in ejabberd? • What is on the ejabberd roadmap ? OAuth !
  3. 3. ejabberd SaaS architecture • ejabberd SaaS is designed: • to be easy to integrate in customers architecture • with scalability and high-availability in mind • to be as stateless as possible • to allow customers to keep control of their data • ejabberd SaaS works in two modes: 1. Statefull: All or most data managed by ejabberd SaaS. 2. Stateless: All or most data on the customer back-end (recommended).
  4. 4. Main issue data duplication = risk of out of sync user base Mobile - Desktop - Web Browser XMPP - 5222 Websocket / Bosh: HTTP - 80 HTTPS - 443 User base manage remotely ejabberd Instant Messaging ejabberd cluster ... Load balancers XMPP - 5222 ejabberd API - ReST or XML-RPC ejabberd SaaS managed by ProcessOne ejabberd SaaS architecture Statefull mode Customer backend Contact list manage remotely ejabberd SaaS database User / password Rosters Message archives Offline messages Last seen Privacy lists Pubsub nodes Push tokens (APNS / GCM) …
  5. 5. Mobile - Desktop - Web Browser XMPP - 5222 Websocket / Bosh: HTTP - 80 HTTPS - 443 ejabberd Instant Messaging ejabberd cluster ... Load balancers XMPP - 5222 User endpoint User calls ejabberd ReST data access layer select one or several backends ejabberd SaaS managed by ProcessOne ejabberd SaaS architecture Stateless mode ejabberd SaaS database Offline messages Last seen Privacy lists Pubsub nodes Push tokens (APNS / GCM) … Roster endpoint (contacts) Roster calls Message archive endpoint Message Archiving calls More to come Data backend managed by customer
  6. 6. What is the best way to archive user messages if we do not want to sync data from user device? • It is not dependent on how whether the user device will sync data or not. • Previously, the XEP for archiving was XEP-0136 - Message Archiving. • This XEP is now obsoleted by XEP-0313 - Message Archiving Management. That specification play nicely with all other newer XMPP features. => This is the specification to use for archiving => even if you do not plan to let user download messages from server archive to client. • Note for ejabberd SaaS: You can implement it in two ways: • Data on ejabberd SaaS server. • Data stored on customer backend through HTTP ReST API calls (Preferred)
  7. 7. Why does ejabberd SaaS not use async mechanisms for archiving messages to customer servers? • An XMPP server is always buffering some data. It buffers offline messages before delivery. It buffers messages send by a client to another connected client that is receiving slowly, etc. • However, buffering makes any a fragile component of the architecture. If you buffer too much, you can kill your central server during peak time. So, 1. For scalability and robustness you need to have all write processed to their final destination as fast as possible => write as you receive the messages. 2. Receiving and writing back-end HTTP calls for messages is easy to scale (i.e. Basho Riak). 3. Customers can implement more features when they receive the archived messages in real-time (Like triggers email). 4. Archiving individual messages make it possible to load balance / shard the back-end (for example based on Jabber ID).
  8. 8. Mobile XMPP support: Explain standby, push and detached modes • When implementing mobile support you need to cope with mobile limitations: • XMPP sessions are originally designed for constantly connected TCP/IP sockets. • Smartphone applications are put to sleep to save battery life. => We needed a way to make XMPP friendly with smartphone operations.
  9. 9. XMPP C2S state machine Highly simplified default XMPP session states Session established Session closed Close stream or TCP/IP connection Open TCP/IP and stream Stream opened Login
  10. 10. XMPP Mobile C2S state machine Session established Session closed Close stream or TCP/IP connection Open TCP/IP and stream Stream opened Login Standby mode (Limit traffic, filter presence) / Inactive client (CSI) Standby / Inactive Enable push mode Active Session with push mode enabled Open TCP connection and rebind to session Session expires Close stream TCP close Detached session Session still opened Can receive push
  11. 11. How does ejabberd internally store messages which are not yet delivered? Message not delivered can be generated in several state: 1. Session is established with TCP connection attached A. If client does not support message acknowledgement Message are directly send on TCP and deleted from memory. B. If client support message acknowledgement Messages are buffered in the session until acked by receiving client. Messages are stored for offline delivery if the session timeouts without receiving message acks. 2. Session is established in detached mode: • Messages are buffered in the session and are send on reattach. • Messages are stored for offline delivery if the session expires before reattach. 3. There is no session for user: • Message are directly stored in offline storage.
  12. 12. How are privacy lists managed in ejabberd? • ejabberd supports: • XEP-0016: Privacy lists • XEP-0191: Blocking Command • Both specifications can be used together on a single back-end. • Data are stored in ejabberd database (various databases possible). • No ReST backend for now for performance reasons.
  13. 13. What is on the ejabberd Roadmap ? OAuth ! • ejabberd 15.09 is about to be release. • It will include OAuth 2.0 support for ejabberd. • This is a huge feature that has been in development for several months. • Features: • Security: Set-up login in client without sharing password with client. • User can delegate rights to others third-party applications. You can let a third-party service send message or post in chat room on your behalf. (Slack-like) • Make ejabberd a central piece in a micro-services architecture. • Internet of Things support: Your things can do stuff for you without the need to fully speak XMPP. • Build an ecosystem: Grant limited rights to your partners.
  14. 14. ejabberd 15.09 + OAuth =
  15. 15. See you at next

×