way to inform rev apps to get something from web server
alex at tweedly.net
Sun Feb 15 18:57:05 EST 2009
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
More information about the Use-livecode