Well the memory leaks and approach to fallback connections led to it being more sensible to roll our own. We've only needed to handle concurrent connections in

Well the memory leaks and approach to fallback connections led to it being more sensible to roll our own. We've only needed to handle concurrent connections in the 1-10k range though. There are really better c++ and erlang implementations we've investigated but won't pull those off the shelf till needed. Obviously there's loads of great realtime-as-a-service offerings like Firebase and Pusher that make sense for a lot of use cases, just not ours. We were always uncomfortable with relying on a third party for a core aspect of infrastructure, and this acquisition introduces uncertainty that we don't have to worry about.