Overview

Our automatic deploy has a couple ways to operate.

The first is the fastest and fully automatic, in that setup we 'tell' your server as soon as an update is available that should be installed, and we pass it (push it) to your server. It is called 'listening'.

Polling is reverse of listening. In polling tentacle, the agent (client) talks to the server from time to time and asks if there are any update.

Two terms that come up:

Agent is the machine on which the software is installed and running.

Server is where we put upgrades for the Agent to get.

In a listening setup, the server talks to the Agent says 'install this'. A listening setup has very little bandwidth – if there are 2 weeks between updates, then the only communication is every two weeks.

In a polling setup, the Agent talks to the Server and says 'Give me an update if you have one.' A polling setup has more bandwidth, if you set it up to poll every 15 minutes and there is on average one update every two weeks, 1344 communications per update.

Why choose Listening?

When it is allowed on the network this is usually the best. It allow us to push you bug fixes quickly, often before you even know you have a problem. It is the lower bandwidth.

But it doesn't always work – some companies have firewall rules, some of which go in and turn off the ability to listen shortly after you have tested it. Some may run every 24 or 48 hours to 'plug' so called leaks. While ours obviously is not a leak, it can be difficult if your IT department doesn't know how they are set up and/or they don't want to allow it.

Why choose Polling?

Usually it is easier to get your IT department on board (in many cases they have nothing set up to block it because it is initiated from inside and therefore is considered 'safer'. While for unknown products this is probably true, with known products like ours it really doesn't make it any safer, but it may be easier to just go with polling.