way to inform rev apps to get something from web server

[Alex Tweedly]

Jim Sims wrote:
> Here is what I want to do:
>
> Lets say I have a large number of rev apps that will go to a web 
> server and grab some data/image when told to do so (when given a 
> signal to do so).
>
> I could have these apps poll a text file or something on a web server 
> every so many minutes but I want a less 'bandwidth wasteful'  way to 
> inform these apps to act.
>
> What is the best way to do this? UDP? TCP server/client? Something else?
> What obstacles might I encounter?
When you say  "large number of apps", do you really mean "a large number 
of users, for one or more apps" ?
and, what do you mean by 'large' ? 10s, 100s, 1000s, millions ?

How urgent is it that they get the update once it is available ?
How essential is it that they are informed quickly ?

What kind of users / environment are you in ?

If it's over the Internet. with general end-users then you need to deal 
with firewalls and NATs - so probably need to avoid UDP, and can't do 
any server-triggered TCP connections. That leaves polling of some kind 
over TCP .... but polling a text file may not be the best way; instead, 
create a CGI script that takes a URL containing the last 'version' or 
'timestamp' that the client has already picked up, and gives a reply 
telling the client whether to proceed or not.

If you don't need to deal with (or can control) firewalls / NATs then do 
the same polling, but use UDP for it - this makes each poll be 
(typically) only 2 packets, rather than the 4-6 minimum for TCP (so 
lower bandwidth, and much lower overhead on the server). Though that may 
not matter if 'large' only means hundreds or a handful of thousands 
(remember: 1000 users polling every 4 minutes is only 4 requests per 
second - hardly noticable to a decent web server).

If firewall/NAT is not an issue, and updating is urgent, and numbers are 
truly large, then consider the more complex scheme of having a longer 
pollling cycle (say every 20 minutes), but part of the polling informs 
the server of the client's IP address/socket, and the server sends a 
trigger (e.g. UDP) when there is an update available.

btw - are the updates/events truly random timing ? or could the server 
have some idea of when the next update will be available ?  If so, have 
the reply to the polls include an estimated 'next event time', so the 
client can vary his polling cycle.

And also consider trying to keep the polling times random. You want to 
avoid the case where the clients will align their query times, causing 
surges of queries (and indeed of eventual updates); the simplest way is 
probably to make the pollling times be (say) 120 seconds +/- random(20 
seconds).

-- Alex.