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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
