<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">There is no hard requirement for a
RESTful API, but since this API will be used in a wide variety of
places (e.g., web/html5 games, mobile, flash, etc) and not just
internally, we decided having a RESTful API would be a good idea
and make using the API in development quicker/easier.<br>
<br>
On 12/6/2012 18:42, Steve Davis wrote:<br>
</div>
<blockquote
cite="mid:51c212fa-185d-45e1-ad97-815ce1cde94f@googlegroups.com"
type="cite">From what you've said, I would guess that the correct
answer is:
<div>2) memcached protocol</div>
<div><br>
</div>
<div>Since </div>
<div><br>
</div>
<div>Your solution (1) starts with "When a client requests data on
a player, spawn 1 player process." If that had been "when a
client requests data on themselves from another game" then it
could have been in the running...</div>
<div><br>
</div>
<div>A memcached implementation will sort out LRU without you
having to reinvent (stabilize, test) a wheel.</div>
<div><br>
</div>
<div>Not sure why there's a REST requirement. If this MUST be HTTP
then I see it, otherwise what does it do for you?</div>
<div><br>
</div>
<div>My 2c,</div>
<div>/s<br>
<div><br>
On Thursday, December 6, 2012 3:43:22 PM UTC-6, David Fox
wrote:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I'm
currently developing a gaming server which stores player
information <br>
that can be accessed from any of our games via a REST API.
<br>
<br>
So far I've thought of two ways to structure and cache
player data:
<br>
<br>
1. When a client requests data on a player, spawn 1 player
process. This <br>
process handles: all subsequent requests from clients for
this player, <br>
retrieving the player data from the DB when created and
periodically <br>
updating the DB with any new data from clients. If the
player is not <br>
requested by another client within... say 30 minutes, the
player process <br>
will terminate.
<br>
<br>
2. Just keep previously requested data in a distributed LRU
cache (e.g., <br>
memcached, redis, mnesia)
<br>
<br>
Out of the two, I prefer #1 since it would allow me to
separate the <br>
functionality of different "data types" (e.g., player data,
game data).
<br>
<br>
There are just 2 problems with doing it this way that I'd
like your <br>
thoughts and help with:
<br>
I. I would have to implement some sort of "LRU process
cache" so I could <br>
terminate processes to free memory for new ones.
<br>
II. If a load balancer connects a client to node #1, but the
process for <br>
the requested player is on node #2, how can the player
process on node <br>
#2 send the data to the socket opened for the client on node
#1. Is it <br>
possible to somehow send an socket across nodes? The reason
I ask, is <br>
that I'd like to prevent sending big messages across nodes.
<br>
<br>
Thanks for the help!
<br>
______________________________<wbr>_________________
<br>
erlang-questions mailing list
<br>
<a moz-do-not-send="true" href="javascript:" target="_blank"
gdf-obfuscated-mailto="eJX3uogvCAsJ">erlang-q...@erlang.org</a>
<br>
<a moz-do-not-send="true"
href="http://erlang.org/mailman/listinfo/erlang-questions"
target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>
<br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>