>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 

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 

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 

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 

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 

that I'd like to prevent sending big messages across nodes.

<br>

Thanks for the help!

<br>______________________________<wbr>_________________

<br>erlang-questions mailing list

<br><a href="javascript:" target="_blank" gdf-obfuscated-mailto="eJX3uogvCAsJ">erlang-q...@erlang.org</a>

<br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>

<br></blockquote></div></div>