Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modular architecture #90

Open
sebpiq opened this issue May 21, 2015 · 6 comments
Open

Modular architecture #90

sebpiq opened this issue May 21, 2015 · 6 comments
Milestone

Comments

@sebpiq
Copy link
Owner

sebpiq commented May 21, 2015

Look into using redis for pub/sub instead of the ConnectionManager.

This would allow to scale, and have several rhizome servers communicating together through a queue system.

@sebpiq sebpiq added this to the 0.8.0 milestone Aug 7, 2015
@sebpiq
Copy link
Owner Author

sebpiq commented Oct 21, 2015

@sebpiq sebpiq changed the title Use redis for pub/sub Use a decentralized queue system for pub/sub Oct 22, 2015
@sebpiq
Copy link
Owner Author

sebpiq commented Oct 31, 2015

Or maybe we don't need a separate queue, but rather proxying directly the messages from one server to the next. Each server registers itself to the others, so they can communicate together. Or maybe it could be a setting rhizomeInstances with IPs of all other rhizome servers running ... but in any case, we need a centralized database to save persistent info

@sebpiq sebpiq changed the title Use a decentralized queue system for pub/sub Modular architecture Oct 31, 2015
@kirbysayshi
Copy link

Another option might be the cluster module built into node, and each cluster keeping track of its own connections like now.

@sebpiq
Copy link
Owner Author

sebpiq commented Dec 10, 2015

I don't think this would work. If a client disconnects and reconnects, it might be handled by a different server of the cluster, which doesn't have infos about the connection.

Besides, I want also to be able to run servers on different machines for maximum scalability.

@kirbysayshi
Copy link

Cool, the cluster thing was just an off the cuff idea.

@sebpiq
Copy link
Owner Author

sebpiq commented Aug 22, 2016

Now redis persistence is available, which should solve the cluster problem, and allow this to move forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants