AMQP vs. XMPP

Here is a goog blog post  http://saladwithsteve.com/2007/08/future-is-messaging.html.

XMPP servers

Open-source XMPP server comparison chart http://www.saint-andre.com/jabber/jsc/

Also this Wiki page  http://en.wikipedia.org/wiki/Comparison_of_XMPP_server_software

IMF candidates

  • coversant soapbox server http://www.coversant.net/product/soapboxserver.aspx is a good candidate for its scalability, archiving extension developed for DOE, and C++ library, however it requires Windows.
  • jabberd 2.x  http://codex.xiaoka.com/wiki/jabberd2:start is the next generation jabberd, but unfortunately does not have Pub/Sub support
  • ejabberd (Erlang Jabber Daemon)  http://www.ejabberd.im/ is probably the most popular XMPP server for its stability. Some interesting features include:
    • dynamic code loading: if you have a new ejabberd module, you can load it dynamically without restarting the server
    • live console: you can open an Erlang Shell inside a running ejabberd
    • easy clustering - scale well
  • Openfire  http://www.igniterealtime.org/ is written in Java. The main strength is it's very easy to install and manage, due to its powerful Web GUI. However, performance and stability are not their biggest concern.
  • Tigase http://www.tigase.org/ is also Java based. Comparing with Openfire, it has a better scalability. However, it only provides command line configuration.

Discussion

Among all XMPP servers that have active communities, only a few of them have good Pub/Sub support, i.e., coversant soapbox server, ejabberd, Openfire and Tigase. coversant soapbox server is left out because it requires Windows OS. ejabberd is also a good candidate with some nice features, but learning a new language (Erlang) may not be worthwhile. Between Openfire and Tigase, one important difference is that Openfire is under Open Source Apache License while Tigase is under GPL 3.0.

"Federation"

From XEP 0238  http://xmpp.org/extensions/xep-0238.html :

XMPP Core [1] describes the client-server architecture upon which Jabber/XMPP communication is based. One aspect of such communication is "federation", i.e., the ability for two XMPP servers in different domains to exchange XML stanzas. There are at least four levels of federation:

  • Permissive Federation -- a server accepts a connection from any other peer on the network, even without verifiying the identity of the peer based on DNS lookups. The lack of peer verification or authentication means that domains can be spoofed. Permissive federation was effectively outlawed on the Jabber network in October 2000 with the release of the jabberd 1.2 server, which included support for the newly-developed Server Dialback [2] protocol.
  • Verified Federation -- a server accepts a connection from a peer only after the identity of the peer has been weakly verified via Server Dialback, based on information obtained via the Domain Name System (DNS) and verification keys exchanged in-band over XMPP. However, the connection is not encrypted. The use of identity verification effectively prevents domain spoofing, but federation requires proper DNS setup and is still subject to DNS poisoning attacks. Verified federation has been the default service policy followed by servers on the open XMPP network from October 2000 until now.
  • Encrypted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) as defined for XMPP in XMPP Core [3] and the peer presents a digital certificate. However, the certificate may be self-signed, in which case mutual authentication is typically not possible. Therefore, after STARTTLS negotiation the parties proceed to weakly verify identity using Server Dialback. This combination results in an encrypted connection with weak identity verification.
  • Trusted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) and the peer presents a digital certificate issued by a trusted root certification authority (CA). The list of trusted root CAs is determined by local service policy, as is the level of trust accorded to various types of certificates (i.e., Class 1, Class 2, or Class 3). The use of trusted domain certificates effectively prevents DNS poisoning attacks but makes federation more difficult since typically such certificates are not easy to obtain.