Search for Alternatives to XMPP/Jabber/libjingle

[mmehr2]

The code for MSW currently contains code for a Remote feature implementation. This was written using the 3rd Party library libjingle, which was the officially supported Google code to access the XMPP/Jabber protocol used by Google Talk and its chat server system. The library is extensively documented here.

I encountered several problems with libjingle itself in the code initially. After a few days of fixing those, I finally noticed that talk.google.com, while still responding to ping requests, didn't seem to be allowing any authorization of my Gmail address. Come to find out Google has dropped support for Google Talk last June 26, 2017. This seems to mean that the servers are shut down from allowing future usage. Thus began the search for alternatives.

I discussed this with various folks and came up with a few ideas.

1. Attempt to find a replacement for the XMPP server. The best seems to be ejabberd. I downloaded it and successfully ran it on my test machine, but was unable to make it respond to the libjingle requests, although I had proof that the traffic was being blocked by my firewall on the test machine. However, opening that port did not solve the problem. The server is well documented but complicated and no fixes were apparent. More work needed here was pre-empted by the alternative search. Exact behavior of MSW is that the attempt to contact the server for authentication times out (officially reported as follows: Warning(physicalsocketserver.cc:1072): PhysicalSocketServer got FD_CONNECT_BIT error 10060 Discussion of error 10060 on Google search results implies various timeout issues.

2. Look for another method of M2M (machine to machine) communications over the Internet. Noticing the similarity here to popular developer memes of the moment, i.e., IoT (Internet of Things), it was suggested I look into the Pubnub service and/or an MQTT solution.

3. I tried Pubnub first. There have been various issues which I will document separately in this ticket #4

4. Next alternative can be to find an MQTT client such as Mosquitto or Paho. Even Pubnub seems to support it, but I can get no mention of it in their developer docs (very new feature), and no idea if this is included in their price plans.

This issue will be for discussion of the alternatives until a successful one is found.

[mmehr2]

Looking at Eclipse Paho at eclipse.org/paho/clients/cpp we find that the minimum supported compiler for C++ (since they used C++11) is Visual Studio 2015. As stated elsewhere, this is a technical debt issue for the project that we may find in other alternatives as well. It's expensive for providers to maintain compatibility with old compilers and VS2010 at 7-8 years old is pretty old software!

If possible, we can try the C interface. The prebuilt binaries require VS2013 runtimes, but perhaps VS2010 can rebuild the source. Time (and experiments) will tell.

[mmehr2]

Currently doesn't build, but will keep after Vladamir. Michael Maltese in Sales contacted us today, I will speak with him next week if this looks viable, or postpone until it does. May need to drop this. Less urgent while I work on the CustomComm version.

[mmehr2]

We are going with Pubnub in spite of some uncertainties as to fit. Michael Maltese (sales dev.engr.) and I discussed our usage. We need to keep all this under one account (for billing purposes) assigned to Eric. So we are talking messages and daily devices across all the distributed customers of ECS Video. If Free Tier can't be made to work for the first few devices, it may still be an issue, although $50/mo isn't bad. But the customer wasn't willing to pay extra for these. Still, if it works, I remain confident these issues can be addressed.

The build issues were solved after an email response and a head smack. :) So, we are using the Pubnub service for the time being, and I will close this issue now, and reopen it if we revisit our decision.