Databases
StackOverflow2013
Postsdbo
POthe way to synchronize state between distributed clients
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POthe way to synchronize state between distributed clients
    primarykey
    data
    text
    <p>Here is my problem:</p> <p>My application is a distributed real-time message broker for web applications. Clients from web-browsers connect to one of the application nodes. Those nodes connected by ZeroMQ PUB/SUB mechanism. If one client sends message - node publishes it into PUB socket, other nodes receive those message from SUB socket and send it to their own connected clients.</p> <p>But now I need presence and history functionality. Presence - provide a list, containing description of all connected (to all nodes) clients. History - provide a list of last several messages sent. I.e. I need to get entire state of application. I consider several ways to achieve it:</p> <p>1) Send all information about connected clients to central server. Then when a client asks for presence - ask central server and return response to client.</p> <p>2) Keep all information on every node. When client connect to any node send information about it to other nodes - using PUBLISH operation. So when a client asks for presence I can immediately return a response.</p> <p>3) Gather information on demand from all nodes. I really can’t imagine how to program this at moment but this allows to get rid of duplicating information that leads to reducing memory consuption. In this case I don’t need to worry about fitting all information in memory.</p> <p>4) Use some distributed data store, something like <a href="https://github.com/ha/doozerd" rel="nofollow">Dooserd</a>. But I don’t like this idea because of extra dependency.</p> <p>Client needs presence information on every connect to the node, presence information changes on every client's connect/disconnect, history information changes on every message.</p> <p>This is an open-source application, so I don't know how much connected clients it must support. Load tests in the end will say this number.</p> <p>There is no strong requirement about reliability of those presence and history data.</p> <p>I really need your advice, which of these options is the right way to solve my problem. Or maybe there is another better way?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USAlex Emelin
    1. USAlex Emelin
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POthe way to synchronize state between distributed clients
      1. USAlex Emelin
      1. VTBountyStart
    2. VO
      singulars
      1. POthe way to synchronize state between distributed clients
      1. This table or related slice is empty.
      1. VTUpMod
    1. COIf it is such a lot of information, what use is the lot of it to the client? Also, will the clients need this information often or rarely, how often will it change, etc.
      singulars
      1. POthe way to synchronize state between distributed clients
      1. USflup
    2. COClient needs this information on every connect to the node, presence information changes on every client's connect/disconnect, channel history information changes on every message to that channel.
      singulars
      1. POthe way to synchronize state between distributed clients
      1. USAlex Emelin
    3. COAlso I've updated a question.
      singulars
      1. POthe way to synchronize state between distributed clients
      1. USAlex Emelin
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload