Comparison of XMPP Jabber IRC and PSYC
- Reasons to use Jabber
- An open IM system, good for holding private conversations with chosen people using OTR encryption. Jabber has a scalability issue which limits you to reasonable amounts of friendships and makes large chatrooms tricky. The XML-based syntax isn't very fast to process, it's unable to deliver encrypted data efficiently (you need to re-encode it) and to encrypt entire payloads in order to protect meta-information such as who is talking to whom. Other than that it is a pretty impressive technology, quite flexible with a huge choice of implementations and extensions.
- Reasons to use IRC
- IRC is politically quite uncool, as it requires operator hierarchies and makes users dependent of them. Still, for many, the historic IRC technology is still the tool of choice to implement large and very large chatrooms. IRC networks run into scalability limits somewhere above 100'000 users and require tricky administration and optimization along the way. Encrypted conversations over IRC are limited as they need to be re-encoded to fit the maximum message size of 512 bytes.
- Reasons to use PSYC
- Since it can provide most of what you would expect from IRC, you could consider psyced before starting an IRC network. PSYC solves IRC's political, authentication and scalability issues and comes with a huge choice of extra features that go beyond what you would expect from an IRC server, still psyced can be used with all the IRC clients you are accustomed with. Up to a certain degree, PSYC and psyced also support things you would expect from Jabber, and even XMPP itself, but you may run into problems depending on your special requirements. psyced is also an XMPP server and gateway at the same time. The PSYC protocol is capable of delivering encrypted data natively, although we're only going to start using that in 2012.
This chart may be of any help or none at all, it's up to you. It tries to summarize what we know about the three involved protocols. Some of the summaries will make you go But why? and the explanation for them is usually within the IRC and Jabber pages themselves or other linked material. Of course you may as well ask over there in psyc://psyced.org/@welcome.
Comparison of Decentralized Chat Protocols
| IRC | XMPP (Jabber) | PSYC | |
|---|---|---|---|
| Native Client Support | regular | extended | beta ¹ |
| Server-Side Intelligence | minimal | regular | extended ½ |
| File Transfer | DCC | out of band | experimental ¹ |
| Telephony | none | Jingle | experimental ¹ |
| Presence Notification | poor & kludgy | rich | rich |
| Authentication | kludgy/async (NickServ) | yes | yes |
| Directory Services | integrated | integrated | limited (by choice) |
| Profile Exchange | minimal (/whois) | regular (vCard) | extended (even custom style) |
| Social Network Functions | none | elaborate | experimental |
| Gateways & Transports | kludgy bots & services | services, protocols, kludgy JIDs | services, protocols, integrated |
| Network Politics | closed/oligarchic | open/federated | open/federated |
| Entity Addressing | one nickspace | entity@host.domain | uniform, multi-protocol |
| Scalability Limitations | shared dynamic database | massive unicasting | intentionally none |
| SPAM Protection ² | medium risk | structural risk, planned strategy ¼ | medium risk, extended strategy |
| Network Reliability | netsplits | desynchronizations, improper closing of TCP | less desynchronizations |
| Network Vulnerability | high | medium | low |
| One-To-Many Distribution Strategy | single-tree multicast per network | none (very inefficient) | per-channel multicast |
| Conference control | large choice, secure only with kludgy ChanServ | MUC (kludgy) | programmable |
| Protocol Syntax ³ | hard to extend, kludgy, no binary data | XML-like: extensible, inefficient, no binary data | extensible yet optimized, framed, binary-friendly |
| Server Software Structure | ircd: efficient, compact, legacy | typically modular, multiple processes and SQL, funny language optional | psyced: modular on the fly, likes decentralization, funny language |
| Choice of Implementations | large | large | small |
| Protocol Specification | RFCs and a lot of divergent flavors | RFCs and a broad choice of extensions | specification in progress |
| Popularity vs Centralistic | smaller | small | smallest |
- ¹) Since PSYC can act as a routing backend for both IRC and Jabber clients, many functions of their native protocols should also function across PSYC networks.
- ²) On IRC a SPAMbot is quickly killed and banned off the network. Jabber (intentionally) lacks this kind of centralized administrational power. PSYC too, but it has a technological plan in the fight against SPAM (see the document for details, also concerning the related Jabber extension proposals).
- ³) None of the protocols are really easy. IRC seems simple at first, but all the kludgy extensions added over the years make it quite complex. XML may give you a chance to make use of an existing parser software, in exchange you get less performance and XML's specific weaknesses. PSYC finally has its own syntax which is very much optimized to the task at hand, but you will have to spend some time getting a parser to work properly. framed means easy to buffer up before parsing. transparent means capable of carrying embedded binary data.
- ½) psyced has the ability to emulate the entire functionality of a minimal PSYC client within itself, this allows you to use any sorts of dumb client apps like telnet or simple applets to join PSYCspace. This opens up for all sorts of atypical gatewaying capabilities when psyced offers functions as rich as lastlog, personal nickspace - yes even HTML rendering of certain user interface elements (Profiles etc) - which would normally be provided by a client. This also offers client programmers the chance to leave several boring jobs to the server (for later or for good) and focus totally on user interface and presentation, making it a much easier task to write a client for psyced than to write a client for IRC or Jabber.
- ¼) There is an architectural risk in XMPP due to the impossibility for servers to distinguish a legitimate unicast from one person to another from a broad unicast from a massive sender to many people. It is however planned to address these issues with captchas and such. PSYC uses its multicast-based subscription logic to autodetect SPAM instead, which is less intrusive to the users. See the SPAM document for details.
ISODE compares XMPP to.. IRC!
Isode, the technology provider to the US Army, has published a whitepaper on M-Link & XMPP Performance Measurements over Satcom and Constrained IP Networks where apples and pears are compared, I mean XMPP and IRC.
At least the way they compare it is pretty useless from the start: They compare compressed XMPP to uncompressed IRC to discover that uncompressed IRC has slightly more overhead than compressed XMPP. Yeah, now that is news!
To make it a little less obvious they call it a whitepaper and avoid publishing actual test data. IRC has been using compressed streams ever since the mid 90s! Well some networks don't use them, maybe even never added them to their derivate of the ircd software, but.. you can compress IRC.
Then they mention the 512 byte limit as a major headache. Well, if you're running your own constrained army network, why don't you raise that limit to say 262144 bytes in both servers and clients? It's just a #define!
But first things first. Since they aren't comparing IRC to XMPP but to "optimized S2S" let's look at Isode's own idea of "optimized S2S:"
The key differences of Optimized S2S relative to XMPP S2S are:
- Use of a single TCP connection (rather than two).
- Reduction of the amount of data needed to establish a connection.
- Removal of all protocol handshakes to establish a connection ('zero handshake').
In other words, they pretty much made XMPP do things the way IRC usually does them. This is good, as you can see for several pages that establishing just one TCP link is a lot more efficient than what XMPP usually does.
When talking about throughput they claim it to be clear that data transfer will require a larger payload – well, it only does for protocols that aren't designed for it – that counts for both XMPP and IRC, but not for PSYC, not even for HTTP.
How Isode managed to make an IRC server written in C and optimized over two decades perform worse on pings than a Jabber server, I have no idea. We only get their results, and they make no sense at all. It is possible that our configuration was non-optimal or that a different IRC server would have given better results. You can bet on it.
If you want reasons why IRC would perform badly, check out the IRC page – IRC would become a problem once there is a large decentralized network with a large database. As long as Isode's set-up only involved two servers and no users on them, IRC can't possibly be worse than XMPP, at least not unintentionally. Maybe you just ran into IRC's nifty flood protection mechanism? Or is it indeed database sync overhead?
- fippo: imo, they got caught by a feature in ircu coded by... bugless! Inspircd behaves you would expect, it is slightly slower (0.88s) on an uncompressed link. Unfortunately, my testing environment did not have TLS support and inspircd does not support uncompressed ziplinks anymore. The "spikes" are caused by s2s ping pong, which is usually configurable.
I like the conclusion: Given the benefits of using a single protocol for tactical and strategic nets, and the wide adoption and modern functionality of XMPP, there seems little reason to look at alternatives. Yes! Of course! Given that the purpose of the research is probably to implement messaging technology for the US Navy, we're fine that you completely ignored PSYC.
See also
- Presence scalability comparisons for various protocols.
- SILC and other technologies if you like.
Categories: IRC | XMPP | Promotion | Solid