way to inform rev apps to get something from web server

[Andre Garzia]

Sims,

I think the trick is not on the client side but on the server side.
Instead of pointing your Rev client to a fixed server, use a balancing
solution, there are load balancers that are able to distribute the
request among multiple servers so that you can scale (add more
servers) as needed without the need to rewrite things.

This way you script your app normally, but on the server you put
enough logic so that you can add more servers to a pool if you see
that it is getting hard to cope with the demand.

One good balancer is 'Pound': http://www.apsis.ch/pound/

With a solution like that you'll be able to plan your scaling needs.

:D

andre

On Mon, Feb 16, 2009 at 2:36 AM, Jim Sims <sims at ezpzapps.com> wrote:
> 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
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>



-- 
http://www.andregarzia.com All We Do Is Code.