Founding history and HQ
Cometchat was built by Inscripts, an IT services company founded in 2009 (India, Mumbai). Both services and product businesses are operational as of May 2016. HQ in Mumbai, India.

QuickBlox was built by Injoit, an IT services company founded in 2007 (Ukraine). It has fully transformed into a product company focusing on QuickBlox in 2013. The company does not operate services business anymore and is solely focused on QuickBlox platform which is funded by own revenues. HQ moved to London, UK in 2010.

StackOverflow N of discussions
(index of popularity among developers):
Cometchat: 114
QuickBlox: 2,522
QuickBlox has exceedingly more mentions on StackOverflow which is a sign of lively developers community and many use cases discussed around integration and customisation.

Production stats
(sorry I don’t have Cometchat stats so providing QuickBlox only):

QuickBlox servers process over 10 billion requests per month (4K per second) of which 320 per sec are chat messages and the rest are API and presence transactions.

Every day 40-50 developers join to use QuickBlox platform, total platform has over 50,000 app publishers registered, from single developers to R&D centres of large enterprises.

QuickBlox platform powers over 100 enterprise customers using it for secure and reliable messaging in sectors of Finance, Healthcare, E-commerce, internal and B2C communication. All these are stand-alone implementations on AWS or on-premise under SLA from QuickBlox tech ops team.

Over 3,000 apps are running live on QuickBlox shared tier.

Across over few hundred EC2 instances, QuickBlox maintains between 99,8% and 99,9% uptime on monthly basis (99,9% on enterprise)

Main differences
Main differences of CometChat and QuickBlox lay here:

– Web-first vs Mobile-first: CometChat is web-based and is being positioned as a chat solution for websites. Its mobile SDKs (iOS, Android) come secondary and are less developed.

QuickBlox has been mobile-first from day one (first built in 2009 were iOS and
Android SDK libraries) and has very powerful native SDKs for all mobile platforms
(iOS, Android, Windows, BlackBerry) along with Javascript for web. Numerous features QuickBlox has implemented natively for all popular platforms are simply not matched by any competition.

– Core messaging technology stack: CometChat uses long-polling which means users receive messages only when their client requests for them. QuickBlox uses XMPP which is a “true” messaging protocol also used by Whatsapp and many other messengers – meaning messages sent as soon as typed. This is also important for presence and signalling mechanisms. XMPP is very scalable and can support hundreds of thousands of users.

– “Web chat” vs “Messaging OS” architecture. CometChat was built as a chat plugin to web-sites. QuickBlox was built as a universal data backend initially competing with Parse etc and it is highly extensible and customiseable thanks to its powerful Users, Content, Custom Objects and Cloud Code APIs. Some customers use QuickBlox not for messaging, but for general data sync across numerous mobile devices, as platform works very well in that context. In 2011 QuickBlox added messaging (XMPP) now integrated with its Users and Custom Objects APIs. In 2013 QuickBlox added video calling and its native iOS WebRTC library is more efficient than official one from Google. Powerful Data + Communication modules form the so-called “Messaging OS” where you can build whatever you want, going low-level if needed.

– Plugin VS Stand-alone App. CometChat built as a plugin, QuickBlox focuses on a) providing a ready stand-alone messenger: http://q-municate.com, http://qm.quickblox.com with source codes available for iOS, Android, Javascript and also as a ChatViewController which includes messaging UI+logic for easy integration into existing apps: http://quickblox.com/developers/QuickBlox_Developers.

As a summary, I would say use CometChat if you want a chat window on your website. Use QuickBlox if you want a stand-alone web app or native mobile apps with functionality and visual appearance as seen in WhatsApp, Telegram and other state-of-the-art messaging platforms.

It is a bold statement but it’s supported by Microsoft, Facebook, Slack and Telegram.
So you can almost say it’s a new reality. Which means new opportunities for all of us. Let’s dissect the issue of chat bots so you come prepared as the land grab is starting very soon.

Is it novel?
Chat bots are not novel. It doesn’t matter though. Now all the pieces are coming together in a way that’s changing the apps landscape.

Chat bot is AI and needs expensive engineers with PhDs and years of research
Not true.
1) Bots don’t all need to have AI elements – recognising keywords is enough and can be coded in few hours
2) The ecosystem is young but a number of bot building platforms are available already: Chatprime, Pandorabot and Chat fuel are just some of those, Slack already has own botkit, Microsoft is releasing its framework and Facebook is expected to do so in near term.
3) Once you have your logic done it’s actually easier to implement an average chat bot compared to a native mobile app as you leverage the existing interface of a messenger app.

Why now?
It seems all the foundation building blocks just got hardened enough for the ecosystem to emerge.
That unleashes the advantages messaging always had:

– Natural: humans always liked interaction that is: 1) instant; 2) natural.
– Accessible: chat apps have billions of users, you’re likely using one of them on daily basis
– Light-weight: having to download another app with custom UI for every pizza shop is not what users want, apparently. Engaging a bot is as simple as messaging someone or adding a contact into a group chat.

Messenger protocols usually are similar but implementations vary so you may expect having to publish a different bot for each messenger app. This should be less problematic than building same app natively for iOS and Android though so once you’ve coded the logic it should be fairly easy to adapt the connectivity to multiple platforms.

Similarly to app stores, bot stores are going to make your product discoverable but you still have to do your home work in regards to marketing.

Future of the bots, what is it like?
I’m thinking about writing a separate post on what future looks like for bots and messaging in general. In brief, these seem to be the major evolution vectors:

What about security and data ownership?
The concerns that enterprises have in relation to messaging aren’t going away with chat bots.

Many businesses aren’t prepared to host their customer data with Facebook or Microsoft. Enterprise CIOs tend to favour on-premise dedicated server setups over co-hosted cloud solutions and they have good excuses for doing so. Custom trust & safety protocols, data protection policies, industry-specific standards in health care and finance; customisation, white-labeling, custom SLAs, you name it. These won’t be addressed by Skype or Telegram which pretty much blocks bots from revolutionising the enterprise segment.

To solve this problem as an enterprise you could build your own messaging app – from scratch, using one of the open-source XMPP servers such as ejabberd, Tigase or Openfire for your messaging backend. Alternatively, you can license it from one of the CaaS (“communication as a service”) providers.

The options you need to look for:

– Dedicated server – you need to have full ownership of your data and full control of your infrastructure so opt in for private cloud / on-premises set up with full access to application and databases for your tech team
– Close-source messenger client – GPL doesn’t really work for many commercial projects so make sure you choose a platform that is able to license under Apache, MIT or a custom commercial license that doesn’t require you to open-source any modifications you make

At QuickBlox we provide both shared cloud and dedicated set-up options from day one simply because enterprises need this kind of security and are willing to pay more for it. This allows us to re-invest into platform R&D and consequently improve the product for both free/small-cheque users (developers, startups) and enterprise, so everybody wins as a result.

The concept of allowing dedicated / on-prem install is usually frown upon in the world of SaaS and cloud. We managed however to find a model that retains the benefits of SaaS/cloud with ones of dedicated server set up. There is no contradiction – with the help of technologies such as AWS Cloud Formation and Docker it is perfectly possible to deploy, serve and upgrade thousands of dedicated servers at once if needed while continuing to leverage the SaaS model.

I like the “Messaging OS” term. Not sure who has coined it first but I first stumbled upon it the Mary Meeker’s “Internet Trends 2014” report (and this, too) and then saw couple mentions in TechCrunch as well and I loved it as it explains best what we’re working on and the added value we create for the market.

Now it is all clear. Market has evolved a level of abstraction higher.

Messaging = new OS

Bots = new apps

It’s like with programming languages when you move up levels of abstraction from binary machine code to Assembler to C to Object-oriented it becomes easier and more fun to build useful things. Doing less work you create more value. This frees you up to explore the unknown and innovate.

So, have fun innovating with bots. Just ensure they obey those Asimov laws, will you

P.S. check out a video of a simple chat bot I created back in 2014 for switching home power socket on and off (in addition to Q-municate open-source messenger app it also uses Raspberry Pi and Powergenie power sockets):

This is very important. Average person doesn’t give a shit about space. Cold war rockets race is in the past so governments invest near to nothing. Legislation for commercial exploitation motivates businesses to start new era of exploration.

So you know what this means – mankind has just improved its scalability!

Not sure if you noticed or not but as my business currently heavily involves OTT communication, I’m pretty sensitive to this stuff, also feels weird when something you’ve been telling your team and discussing internally suddenly becomes a topic of discussion on TechCrunch, in Mary Meeker reports etc.

So anyway, there are messaging platforms that enable you to add chat / video calling into your apps.

Some are around for a while, for example our QuickBlox has deployed first chat server for enterprise client back in 2011.

All of a sudden, however, people start calling these platforms the new Operational Systems.

First, few words on background history enabling all this. You know like in school or low-level computer science paper you always have to start with “state-of-the-art” and how computers get better and better and why what you write about is relevant.

2. DevOps easily manage armies of images and buckets with the help of chefs and dockers.

3. Smartphone in your pocket is running a powerful multi-core Unix OS, a privilege of an expensive datacenter few years back.

OK so next, the problem. Or, rather, OPPORTUNITY. What’s remaining to figure out? What unites apps and their users?

Communication!

Yeah so we’ve figured out everything else – but only recently we started to get decent IM and calling for our hand-held devices.

And next step now is actually enable it everywhere!

Get it? Platforms handling messaging and data streaming are on their way to commoditisation too.

And this is going to be huge. You think there are too many messengers now? How about messenger in every app you use! How about your microwave and fridge, your home, your office and your current project each have their messenger avatar and each can message you and each other?

Simple case #1. A corporate worker is wondering why his internal employee finder app has to be so ugly. Why can’t it have nice chat bubbles, double-tick delivery statuses, avatars, “now typing”, emoticons and all those other sexy things every consumer user gets for free in their Whatsapp.

All this why end users getting mad there. End user doesn’t understand it takes a year to build backend before nice chat bubbles and alerts start appearing. They’ve tasted it elsewhere and now they want it in your product. They want it now. Otherwise they leave.

2. OS core. Then you’ve got basic modules you can’t live without – users database, all those XMPP, websocket and TURN servers, push notification daemons and Kafka queues, data storage, all the interconnections and logic, so say when user is offline from chat (presence = 0) then send them a push notification alert using a custom template developer specified earlier via admin panel. So this is the logic, this is the core of your OS.

3. Drivers. So you have all that core logic but to expose it you need drivers. JSON API plays that role exposing all the services and modules.

4. System apps + IDE for developers. Bare-bone OS is useless. You need an ecosystem of apps, starting with pre-built system apps (dashboard) and an IDE (that’s what software engineers use to build new apps). So that’s your Developers Kit – in our case it’s everything to make that ‘app to WhatsApp’ transition 1) possible; 2) fast and reliable. That requires SDK libraries, code samples, documentation and all those code snippets / APIs implementing various functionalities end users need.

5. Office suite. To make business guys happy, you also need a bunch of other things, not necessary another software, it can be a service contract (SLA), certification of accordance (HIPPA compliance), a possibility to integrate with existing tools they have (MDM, SharePoint, ActiveDirectory), all things handling security, data ownership (dedicated / on-premise hosting).

And then you get the top layer. The visible part of the iceberg.

The messenger.

Or shall we say The Chat Box.

But really it’s like a pipe connecting you with other persons, things and bots elsewhere.

Oh and it’s slick out of the box, easy to use, intuitive, has nice chat bubbles and enables 1,000,000 other things through it such as:

entertainment

telemedicine

e-commerce

gaming

IoT

So what has changed? Not much – just another revolution of technology.

You don’t need that many clones of chat boxes right now. But you won’t imagine living without all those communication pipes few years from now.

Just remember those platforms silently running in background, like invisible titans holding this pipework for you to enjoy. And think – there is a new economy emerging where you can create your own “WhatsApp for X” in a matter of days, make a chat bot and sell it (yay cyber-slavery!); get free high quality video conferencing tech, overlay some crazy emoji and you’re big in Japan. It’s for you to figure out.

This is Step 1 – making your Pi’s be able to ping each other and communicate via UDP/TCP, ad-hoc, peer to peer, without any central router. This doesn’t include making them route packets with 2 or more hops between origin and destination.

Long story short I’ve tried like a hundred different things and as usual a simple thing made it work.

So here it started as a weekend / hobby project trying to learn more about mesh networking and mesh communications. I’ve purchased 2 x Raspberry Pi 2 Model B (below) along with all standard stuff including usb Wi-Fi dongles and set sail with a goal of simply making them ping each other and eventually transfer a file in a mesh / ad-hoc network mode, basically so that none of them is an access point and both aren’t connected to any 3rd access point.

1. Study of the literature

So I started with doing some research finding some existent posts and tutorials:

This one seemed like a blessing but turned out it was for Archlinux and the instructions don’t quite work for my Raspbian. Anyway in this and other tutorials authors kind of assumed RPis are able to ping each other in ad-hoc mode and skipped to discussing next steps, while in my case I couldn’t get that basic thing work at all.

Project Byzantium (This project looked most promising — especially the fact that you can connect to the mesh network and connect to the same node using a single wifi card. However, the list of software they use and their configurations are not readily available.)

CoovaChilli (DNS Redirect to capture traffic and drive it to an internal website.)

The Wireless Battle of the Mesh is an event that aims at bringing together people from across the world to test the performance of different routing protocols for ad-hoc networks, like Babel, B.A.T.M.A.N., BMX6, OLSR, 802.11s and Static Routing.

So I basically read stuff online, tried setting up as per few tutorials and stackoverflow posts and it didn’t work.

I’ve even installed babeld as using it was suggested in 1st tutorial. Babeld got me the “id mismatch in babel-state” error, I resolved it eventually with executing “modprobe ipv6” but babeld didn’t seem to work or help at all.

2. Choose right usb Wi-Fi adaptors

So one thing I discovered digging further is it’s actually useful to have Wi-Fi adaptors:

a) of the same make

b) that are confirmed to support ad-hoc / mesh mode

And funny thing I’ve ordered my RPis separately and they had 2 different wi-fi dongles. I’ve decided to order 2 new ones that were recommended as the ones that definitely support mesh net mode (in this thread for example http://stackoverflow.com/questions/15423325/raspberry-pi-ad-hoc-networking) so went ahead and ordered 2 x “Edimax EW-7811Un 150 Mbps Wireless 11n Nano Size USB Adapter” from Amazon.

I’ve put same settings into /etc/network/interfaces but still no luck.

4. Get them onto same wireless cell

Found out from some tutorials that it’s not only necessary to specify same ESSID (network name) and have same keys or an absence of those, it is also important apparently to get both devices’ wlan0 interfaces to be on the same CELL.

You can find current cell your wlan0 interface is on by executing

iwconfig

You can also check other interfaces around and what cells they are on by executing

iwlist wlan0 scan

So I’ve added explicitly stating the access point cell into /etc/network/interfaces wlan0 configuration:

wireless-ap 11:5F:02:38:5C:45

I’ve noticed that didn’t really help, for example on one of the Pi’s:

CELL as put in /interfaces: 11:5F:02:38:5C:45

CELL as reported by iwconfig: 02:11:87:BF:8F:FF

As I side note I’ve also noticed that specifying wireless channel in /etc/network/interfaces doesn’t help and according to iwlist it would end up on different Cell numeric ID and long ID, but the channel would always be 1.

So anyway I’ve done some rebooting and jumping around and finally was able to get both RPis onto same Cell (so the long ID like this one above 02:11:87:BF:8F:FF was identical on both RPis).

Still no ping.

5. (optional) Install Erlang on both Raspberry Pi’s

5.1. Why do I need Erlang on my Raspberry Pi

“WTF?” says reader.

Well I just had no freaking idea of what to do but as I’m a bit familiar with Erlang and it’s good with setting up nodes and sending messages between them, I thought why don’t I try this. I was also kinda hoping that Erlang takes care of the mesh connectivity as it’s built in there. Well, at least according to tutorials, such as this amazing book: http://learnyousomeerlang.com/distribunomicon, if Alice can message Bob and Bob can message Charlie then Alice can also message Charlie even when she hasn’t met Charlie yet.

Same didn’t work from either RPi. So they were able to receive laptop but not send back.

5.2. Make sure you set the same cookie

Now as I wasn’t able to send an Erlang node message from one RPi to the other or even to the laptop even though being able to receive a message from it, I tried to explicitly connect to the laptop node:

net_kernel:connect_node(‘laptop@10.10.10.5’).

Which rendered:

=ERROR REPORT==== 27-Jun-2015::11:47:08 ===

** Connection attempt from disallowed node ‘pi1@10.10.10.19’ **

Back to reading manuals and I stumbled upon the concept of cookies and basically realised I wasn’t setting them which is the same as allowing nodes to choose their cookies randomly, this way restricting them from connecting.

Indeed,

erlang:get_cookie().

on my laptop rendered:

QHHMBZOKAQGVKRKUVYGC

and sure enough it was a different value on each RPi.

So I’ve restarted each node in a following manner:

erl -name laptop@10.10.10.5 -setcookie FOOBAR

And it helped – I was now able to send and receive Erlang messages from laptop to any of the two Pis and back from Pi to laptop.

5.3. Alice Bob and Charlie ‘paradox’

So back to our Alice Bob and Charlie thing, we have 3 nodes working in a mesh network and one of them can message two others. Each can message back. So Alice <-> Bob and Bob <-> Charlie works. But Alice <-> Charlie doesn’t work. In our case Bob is my macbook laptop and Alice = RPi1, Charlie = RPi2.

Why is that?

Let’s actually check whether each node knows about the other ones:

on laptop:

(laptop@10.10.10.5)7> nodes().

[‘pi2@10.10.10.2′,’pi1@10.10.10.19’]

Good, laptop knows about both RPis.

on RPi 2:

(pi2@10.10.1.2)15> nodes().

[‘pi2@10.10.10.5’]

Which is very odd – this is how it should NOT be, this contradicts the Distribunomicon and other Erlang tutorials – we shall be seeing other nodes that are connected to the one we’re connected to.

So, simply put, if we can see laptop@10.10.10.5 then we shall also be seeing everybody else laptop@ is able see in its nodes().

And then I’m getting this error:

global: ‘pi2@10.10.10.2’ failed to connect to ‘pi1@10.10.10.19′

Same error displayed on RPi1.

So this is very interesting. Of course this probably means I’m stupidly overseeing something simple and fundamental, but at this point it looks like this:

1) I can Erlang message between Laptop and RPi1/2 and can also broadcast via UDP (yay!)

2) I can ping from Laptop to RPi1 and RPi2, can also ping back from either of them to Laptop

3) I still cannot ping or erlang message between RPi1 and RPi2

4) Erlang nodes() on both RPi1 and RPi2 doesn’t admit it knows anything about the other RPi which contradicts one of the core principles of Erlang as laptop@ node shall be passing its knowledge of RPi2 to RPi1 and other way round. It doesn’t work this way at the same time it tries to do something and we get that error above. Very interesting – I’ve broken Erlang with my simple set up!

End of part one – to be continued.

]]>http://scalabilly.com/2015/08/mesh-ad-hoc-network-on-multiple-raspberry-pis/feed/15Scalabilly beginshttp://scalabilly.com/2015/08/scalabilly-begins/
http://scalabilly.com/2015/08/scalabilly-begins/#respondSun, 23 Aug 2015 22:16:20 +0000http://scalabilly.com/?p=5Continue reading Scalabilly begins]]>I decided to start this blog as a central place to share all things around my professional interests such as building SaaS software and the related aspects of technology, marketing, team work and entrepreneurship in general.

Main thing is I’m going to write about things that both: (a) interest me; and (b) could be useful for others. My interests are quite chaotic in their diversity and include SaaS, mobile messaging (XMPP, WebRTC, SIP), mesh networks, product marketing, startup engineering, but also things such as space exploration, practical psychology, computer vision, quantum mechanics, aikido and playing guitar.

The name idea basically comes from scalability (as in scalable software, scalable business) and rockabilly which is supposed to mean in this context we don’t only talk & do tech, but we also have fun along the way.

This is a personal blog, I write it in my personal time and all opinions are my own. I may reference some cases from projects and businesses I’m involved with for the benefit of both the reader and business/project in question. This platform allows covering certain aspects in better detail, something I won’t be able to do in a company/project blog due to format or other limitations. There will be no special effort devoted to staying more un-biased and objective than I am; this blog shall be treated as post-work musings of a guy who still thinks about work and may be biased (and certainly doesn’t mind more traffic and leads coming into his projects), but honestly wants to share some insights or maybe ask questions and initiate discussion to learn more from others.

It would be nice in future to build a discussion platform here where other authors could join and write posts, upload tutorials etc but we’ll see how it goes and if I’m able to maintain steady and useful publications in the first place.