[EAS] CAP Polling Interval Questions

[Harold Price]

At 11:48 PM 5/10/2011, Al Kenyon wrote:
>So, what is the optimal polling interval for a CAP-EAS device?  As an
>engineer at heart I have a tendency to over-specify and, in this case that
>leads me to recommend a very short polling interval.  What do you think is
>the right number? And why?

My opinion - smaller poll interval is better, to reduce the delivery latency.

I also think the polling should be in two steps, and this can be done 
in two ways.  Since most of the time (statistically, nearly all of 
the time), there are no new broadcast-targeted CAP messages to 
receive.  Optimize the system for that.  A poll should return a 
cached response of "nothing to be seen here", as quickly as possible, 
no DB lookups, no ID checking, etc.  The only issue is how to say 
"are there new alerts since when?"  Two ways, by time, or by sequence 
number of the last alert received.  By time requires the polling 
device to have a good idea of what time it is, by sequence number 
requires a way of giving a sequence number.

In any case, the device connects, asks for new messages since time x 
(or sequence x), and gets a no.  This is takes a very small number of 
packets, and a very small number of bytes, and a small amount of 
sever application CPU cycles.

If, in the unlikely event that the answer is yes, there are new CAP 
alerts, then we can go to step two, get list of CAP messages.  That 
can and should be in two steps as well, first a digest of messages, 
with enough data so duplicates can be detected, and possibly areas 
can be determined, so the device can only fetch the full cap message 
for alerts it is likely to be interested in.

The next step is to fetch the CAP message itself.  That will be a 
little larger, 2 to 4k.  It could be stored via a distributed edge 
type system, if the files get to the edge quickly.  The final step is 
to fetch the audio file itself, which can be up to 1MB. Again, a good 
candidate for an edge network, provided the files get there quickly enough.

So, we need two applications, one optimized to say "no alerts 
present", and one to get the alerts delivered quickly.

Can these run on the same system using RSS or ATOM, and skip my fast 
nothing to do stage?  Certainly.

Is there a way to get the advantages of PUSH (low latency) with the 
advantages of PULL (no holes in firewalls, no list of push targets 
that needs to be maintained).  Yes, simply have each broadcaster make 
a TCP/IP connection to a server(s), and then have the server push 
down that pipe when something interesting happens.  Just like a 
streaming server, but nearly always idle.  What gets pushed can be a 
digest, or the actual CAP message, maybe with embedded audio.  Each 
station could register the areas it is interested in on connect, so 
only interesting alerts would come down that unicast pipe.

Back in 2001, I worked on a system that, with two dual CPU servers, 
ran 10,000 unicast streams (on 9/11, people listening to news 
radio).  Handling 30,000 streams is now easy.

And is 31,000 the right number?  I think it is less, some users are 
sharing a  CAP/EAS device among several stations.  Even with a 
centralized server the load won't be equal to the total number of 
tv+radio+cable.

Also, centralized doesn't mean just one server, at just one location, 
from just one instance of the database.  The nice thing about CAP is 
that is can be delivered from and to a variety of different servers, 
using a variety of different methods.  While the first step may be a 
relatively centralized, small number of servers, that is not how the 
system will end up.  But even that is a good first step, and can 
provide better service than what we have now.

Harold