way to inform rev apps to get something from web server
Jim Sims
sims at ezpzapps.com
Mon Feb 16 00:36:53 EST 2009
Thank you Pierre and Alex.
On Feb 16, 2009, at 12:57 AM, Alex Tweedly wrote:
> 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 ?
I'm discussing the development of a promotional marketing tool with
someone who services the internet gaming industry here in Malta
(poker, bingo, casino, etc.). About ten years ago he did something
similar with a software company that went on to sell a license to the
BBC. They had problems when they tried to scale to the large numbers
of users the BBC threw at them. So, a few thousand users would be the
starting point. Most gambling companies have around 3-6,000 hardcore
users but tons of occasional users.
> How urgent is it that they get the update once it is available ?
> How essential is it that they are informed quickly ?
As we are talking marketing communication, it does not need to be
within seconds, but within minutes would be nice.
> What kind of users / environment are you in ?
Individual users who would be doing this from their home machines
(mostly). Some might be doing it from work environments but that would
be 'bad behavior' methinks ;-)
> 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.
What I have already concocted is the text file only contains the name
of the last version presented (the name is the milliseconds
plus .txt), when the users application gets that number it checks
locally with a userProp that contains the name of the last version
they saw. I've been thinking of having the polling take place very
five minutes or so as this is not a life threatening situation or
crucial (although Marketing guys can be 'life threatening' ;-)
> 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.
So, firewalls and NAT are the major considerations here it seems.
Control of them is the determining factor over what I can/should do.
If I understand you, then UDP is probably not going to get the job
done as there will be a wide variety of users, all with individual ISP
and firewall setups that are not in my control. Maybe my original
design is close to the mark (polling). Polling every 20 - 30 minutes
is a possibility. Being consistent with the timing so every user has
equal odds is the important thing. I suppose they could poll once an
hour if need be, but being able to say more frequently helps my
Marketing message in selling this ;-)
> 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.
Totally random - when the Marketing dudes want to release some
promotion then they will use this. I would anticipate it only being
used a handful of times per day.
> 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).
As the polling will initiate according to when they start their
application then it should be random anyway.
Thanks for the extensive reply Alex!
sims
More information about the use-livecode
mailing list