XMPP — Good as a Open-Source — Deadly as Commercial
This article is about what we learn from XMPP + Openfire + Pixart project together
What new things we should implement in new IM project
- Checking devices category and versions, and their application protocol version for preventing older ones
- Sending some sort of “Acknowledgement” to client when client tries to send some message to server. This will be better in term of UX provision
What was the problem, that we decide to create new project
Open Source is a big unknown black hole
When you have no time to develop big things, first thing you think about is using open source projects. Open source projects have some purposes to be made, some companies creates libraries and then support their projects, some groups of developers will create open source projects just for fun, some of them create projects for designing big uncommercial protocols and so on. In WE-PROJECT we used XMPP protocol, without considering its inefficiency for mobile devices, and without considering our needs. We have no time, then we used this protocol and then used Openfire as server.
Openfire has no built-in scaling feature, so we should provide out of box clustering feature to it. This is the beginning of mess programming :smile:. We had same issue at client side too, in addition to using uncommercial protocol, we faced with very messy codes (some classes was around 20000 lines of codes, 100–300 lines per functions, not clear dependence graph, no use of famous libraries for solving little features in app and so on) , and many bugs too in Pixart project.
As a project manager, i saw some patterns in term of using open source projects. If you are using just a library or DB or something like that, go for it, Do not use open protocols if you have no idea about it, Do Not use open source project as your whole logic if you have other considerations or other needs on top of that open source project.
Mobile is First
At start time of project, i wasn’t know about this fact witch mobile applications is so important in social network apps. XMPP is not suitable for mobile devices. It is using XML as streaming payload, not clear plan for offline messages, no plan for saving efficiently and retrieving them in mobile devices and so on.
At the beginning of project, we implement many things to create more reliable and power efficient application, but until now, we haven’t such a thing.
Complexity
XMPP is a open source project with many minor protocols, some of them will be supported in some open sourced servers and some of them not. These minor protocols needs to be backward compatible, some of them are deprecated but there is no substitute to them, so them will be used even after depreciation. So we have a very complex protocols to implement. For example, “Bookmark” and “Roster” has same purpose of designing and using, but they are very different protocols in term of implementation. Further that, “Bookmark” protocols is so unreliable and has a bad designed steps.
For a little information you should query many things from server, then decide which you want to show to the user.
Unnecessary Presence
In XMPP we have unnecessary protocol, named Presence. I have no idea about its design, why we need to join to the same room every time we logged in to the application, why we need to send some presence message to server when we are fully connected to the server, and servers knows we are connected too 😄,WTF.
Like other major packets in our application, like messages, and queries, we have same amount of presence packets without any reasonable designing issue.
Multi-User-Chat, Deadly Protocol
For implementing channels and groups, we had to use MUC protocol (XEP-0045). In this protocol, there are many issues:
1. Sending presence every time you connect to the server.
1. There is no obvious and complete solution about inviting and kicking peoples in them.
1. There is some bugs in joining progress into them.
1. No good support of none privileged users in MUCs, like channel visitors.
1. There are some sort of unnecessary privacy issues, like setting nicknames in MUCs.
and so on.
XML
We had many researches about selecting best protocols in new project, we found Google Protocol Buffer and GRPC. XML and JSON are so inefficient versus GRPC, in some cases, GRPC is about 10x time faster and 70% less networking packet size. XML is so flexible, but, in social network apps is a nightmare.
Consider we have 1,000,000 messages per seconds, every 1KB more packet size, will be more 1GB bandwidth.
In GRPC we do not send schema of data, we just send data itself, but in JSON and XML we are send data and schema together. Parsing is other advantage of GRPC. GRPC will parse packet in O(n) but XML and JSON parse time are about O(N²) or O(N³), so in mobile applications, GRPC are better.
In between server nodes, GPRC is more efficient rather than XML, in XMPP all packets between nodes, will be transferred by XML.
Socket Based
There are many issues with sockets in data centers. We had long time problem with opening ports on data centers, and many problems with load balancing them. in GRPC and HTTP/2 we had no issue about it, in all data centers, port of 80 and 443 are open.
Socket programming, is too much low level, hard to be implemented in applications.
Openfire Problems
1. Clustering and Scaling
1. Routing problem in MUCs
1. Authentication should change -> many issues (1- Security risks, 2-Stopping spoofing sessions)
1. Cache needs to change, in term of security and performance
1. Some issues in firebase in term of performance
1. We have no proper tests in none of each plugins of ours
1. We should integrate our features in app anyway and prevent from just using plugins in production -> so hard to deploy and very expensive in term of using resources
There is more
There is more commercial needs in our application. This is so hard to implement them in the middle of this giant black hole of codes. We need reconsideration of using XMPP, Openfire and Pixart and we should develop this project on top of big open sourced libraries instead of using big open source project like openfire.