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!


More information about the Use-livecode mailing list