Why token based polling: Partial success and command synergy

October 21, 2015 / 0 comments / in Measurement  / by Jacob Allred

In my ongoing theme to further educate you all on the reasons to use token based polling (otherwise known as Request New Device Data) we find ourselves on our 2nd installment of the series. In my previous post we covered the Reduced Overhead of the command. This time we’ll cover Partial success and Command synergy

Partial Success

Token based polling is quite good at knowing where data should be, that’s why there are no missing data holes when using token based requests, but it’s also good at knowing when communications ceased or failed during communication with the device. When failures occur mid-poll when using a date-based history poll, there isn’t a reliable way to know what data was already collected and what was still yet to be returned. The only way to reliably ensure that the correct data was being reported for that period was to throw out the failed transaction and hope the next attempt would be successful. This problem can be exacerbated further if you throw in poor communication infrastructure. Each passing hour reduces your chances of success!

Introduce token based polling. Since our drivers know which index we last successfully collected from the device, we can keep track of where we left off with the device. If a failure occurs, we simply store the index where we last had successful messages from the device and mark the history as a partial success to be passed to the measurement system (CygNet Measurement). On the next scheduled poll, we’ll pick up from the index that we last left off at. For those who are working with the older Totalflows, be aware that they don’t support partial success. This is because their toolkit (tcidll.dll) does not support partial success for the older devices. If you have Totalflow field devices, and you want to leverage partial successes, you will need to have a DB2 Enhanced capable device and the latest tcidll.dll to support it.

Command synergy

Double polling history in the field device should be avoided if possible. This is wasted time on the wire, wasted communication costs, and wasted storage space of data. With the introduction of the token based requests, it is now possible for users and automation to synergize their requests. When issuing a request to the device the question being posed is always the same, “What new records do you have available since the last time we talked”. Let’s say that you have a scheduled poll every day to grab your measurement data at 10am each morning as that’s when the contract day ends/begins. Bob gets into the office at 8am and decides to poll for history against a device that has just come back online after being down for the last 3 days. If Bob’s request is successful, he will have just collected all but 2 hours of the current contract day. In about 2 hours’ time, the scheduler will kick off a request for that device. If Bob and the scheduler are both using the new token based request, then the automated request will only return 2 hours of data. This is because the scheduled poll will simply ask the device what has changed since the last communication attempt (in this case, Bob’s last successful request from the device).

There are just two additional reasons to move from the old date based polls to the new token based ones. If your communication infrastructure is having trouble returning data reliably or if you have users who demand poll for history, you should look into leveraging the new functionality. It will reduce comm times, reduce communication costs, keep duplicate data out of your databases, and make life a little easier for you.