CE WebSocket v SSH v HttpFeedback. Which is Best?

I thought this would be an interesting comparison to write code for all three different connection types in their most simplistic form and do a comparison. Cisco collaboration endpoints now have three main methods to get data from an endpoint over the network ( I am not talking about a serial connection) for the purposes of interacting with the endpoints API. They are WebSocket, SSH and HttpFeedback. The example I am using in my comparisons is based on a very simple idea of I want audio status changes to be pushed to my server from the collaboration endpoint. In my examples I am using a Webex Room Kit to send commands to. If you don't know what that is stop reading now this post is not for you.

I am a part time Nodejs developer (I think so, so to hell with everyone else) so all the examples I am going to post will be in JavaScript. I am not the most elegant of developers though. I basically create stuff that works for the purposes of prototypes so don't expect JS ninja magic. My examples are good enough though for most to get the idea of what the hell is going on.

Lets get on with it....

Webhooks

This example comes to us from Magnus's Cisco Community Post.

Magnus created a nice clean Node example, so I am going to rip it right off of him.


A couple of things of note. This example uses two main libraries, JSxAPI and ws (WebSocket) libraries both of which are on NPM. Its a simple setup and responses from the endpoint are very quick. What I love about WebSockets is that you can use it over port 80 or 443 and using the WS library makes coding your WebSockets install very easy and clean.

There are however some considerations to make. If you are scaling out you application, just like SSH which I will get into in a minute, you now have to start thinking about how do I manage persistent connections potentially across multiple servers. Running everything on a single server should be pretty easy but on multiple servers connecting to a database can be much more difficult depending on what your trying to achieve. In saying that most use cases for using the API on a collaboration endpoint usually only requires to scale to just a few hundred endpoints or less which a single Nodejs server will easily handle.

An important point which also applies to SSH is how much chatter will there be from your endpoints. If you a monitoring a lot of events and status which causes a constant stream of communication your scale will ultimately be diminished. A single server can comfortable handle thousands of WebSocket connections if they are relativity idle most of the time but if your chatter from every endpoint is high then this brings down the amount of concurrent connections and something to monitor as you scale.

SSH

Talk about simple brah! SSH is even simpler from a coding standpoint as the JSxAPI library has the SSH2 library as a dependency you can just launch and control the session using the JSxAPI library.


While having an SSH library as a dependency is helpful at time this can be a little bit of a hindrance as well. If things go wrong you have to pull the covers back a little to explore how the two libraries work together and generally I have found scaling this out to anything beyond a 100 endpoints is more bother than it's worth. Connection failures, dropped connections etc etc just become a pain to deal with once you start connecting to an 1000 endpoints using SSH. Managing the connection state does have some benefits though.

If you know your connected SSH state then you don't have to poll your endpoints to check their state for at least the network connectivity. Event messages and responses are generally fast and there is little code required to create the connection. I have used this method many times when I have a single endpoint I need some form of app or controller to connect to it. My CE-Deploy app is a great example where I have used this method. I only need to connect to one endpoint at a time and the connection gets closed once the work is done to move onto configuring the next endpoint. Its simple and effective.

HttpFeedback

This is the most complex of the three to code but can be the most flexible and scalable. I say this because there is no persistent connection to maintain or monitor. It follows the typical HTTP pattern of request, response and done from a TCP connection standpoint.


If you can excuse some sloppy code (yeah yeah its not perfect) you will see that I used Express to help create a simple web server. I got a little help from a TP client library I use sometimes to help post my XML although this could have been simply done using the request module as well just a little more code. There are lots of options using HttpFeedback as the underlying code listening to the feedback messages is just a web server. The most difficult piece is configuring the client/endpoint to send the events and status updates to the server to start with. You have to let you endpoint know your server URI so it knows where to send its events and this is done using a XML message you can see in the code.

Another complex piece not shown is responding to an event like a user pushing to a button on the touch 10.  Just like registering feedback you now have to create your XML response to tell the codec what to do next. Plus since you are not maintaining a persistent connection how do you know if you should send your endpoint any commands you may need it to carry out. Say at midnight you want all endpoints to reset a setting to your default. this can be done by sending them a XML message to the XML API. With a persistent connection you might be able to work this out pretty simply but now you don't have that. Do you poll the endpoint regularly to check or just hope that it eventually comes back online and everything rights itself? What if you bring you app online and an endpoint is offline, how do you let your endpoint know when it comes online where to send its data. Some of this can be solved using TMS or a management platform but what if this is your own homegrown TMS? This method can be lots of work.

To Sum Up...

There are loads of great API's to work with once you connected to your endpoint and depending on your requirements one connection method might work better than another. For myself, I think for smaller to mid sized projects WebSockets is where I will spend most of my time and for larger projects, well, I will just try to avoid those for now at least :)

Hope you enjoyed the post.

VoIPNorm