<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">I've never heard of this tech before.
      Thanks for the heads up, looks quite interesting :)<br>
      <br>
      On 12/7/2012 13:34, Arthur Ingram wrote:<br>
    </div>
    <blockquote
      cite="mid:269eb6b1-f17a-4ea9-b5f5-02117cc20b2e@googlegroups.com"
      type="cite">
      <div>Take a look at the following</div>
      <div><br>
      </div>
      <div><br>
      </div>
      <div><a class="moz-txt-link-freetext" href="https://github.com/ztmr/egtm">https://github.com/ztmr/egtm</a><br>
      </div>
      <div><br>
      </div>
      <div><a class="moz-txt-link-freetext" href="http://robtweed.wordpress.com/2012/10/22/natively-stateless/">http://robtweed.wordpress.com/2012/10/22/natively-stateless/</a><br>
      </div>
      <div><br>
      </div>
      <br>
      <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>
    </blockquote>
    <br>
  </body>
</html>