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

Pub/Sub Features #15

Open
sosensible opened this issue Jan 3, 2018 · 10 comments
Open

Pub/Sub Features #15

sosensible opened this issue Jan 3, 2018 · 10 comments

Comments

@sosensible
Copy link

Redis is known for clustered scale on Websockets. Do we have this kind of functionality in the Lucee-Websockets? Is there a way to tie these into Redis to serve as the go between in a cluster?

https://redis.io/topics/pubsub

@isapir
Copy link
Owner

isapir commented Jan 3, 2018

Do you mean that for sharing Session information, or balancing the actual WebSocket connections? Can you be more specific on what you request?

@sosensible
Copy link
Author

Load balancing web socket connections was my focus. There comes a time when your server is at capacity or beyond. Either you reject additional connections or ???. The option that many use for websockets is using Redis as the bridge to flow using pub/sub features.

@isapir
Copy link
Owner

isapir commented Jan 3, 2018

That sounds more like a task for the proxy server, e.g. the web server if you're using one in front of your servlet container. I'm not sure how implementing that into the extension would be beneficial.

@sosensible
Copy link
Author

sosensible commented Jan 3, 2018

If it were the traffic you were balancing perhaps. With a websocket the messages have to be distributed to the right people across systems. A proxy server would not be able to effectively distinguish what the client was subscribed to within the cluster. That distribution is what is being done by Redis. Perhaps it needs a different extension but a proxy server is not the answer.

@isapir
Copy link
Owner

isapir commented Jan 3, 2018

I think that I understand what you mean now.

So you're saying that an incoming message will go to Redis, and then Redis will send that message to all of the subscribers? Or to all of the Lucee servers which will then will send the message to all of the subscribers?

@sosensible
Copy link
Author

Right, think about how Slack would work internally. You could not target all the chatter for a channel via a proxy server. Redis lets someone hit the server they hit, and then it subscribes to a channel published on the cluster. Scale becomes much easier.

@isapir
Copy link
Owner

isapir commented Jan 3, 2018

I don't have any time to look into this ATM.

One solution that I can think of, though might not be as good as the Redis one, is to maintain a list of your Lucee servers, and send the details of an incoming message to them via an http request. Then have those servers send a websocket message to all of their subscribers.

@sosensible
Copy link
Author

Thanks for the considerations. We have a month or two to figure this out before it hits our weekly sprint.

@dawesi
Copy link

dawesi commented Aug 21, 2018

I agree with isapir initial comment, you're mixing infrastructure into apps. The two should be separate.

@redtopia
Copy link

Using AWS for example, a load balancer could be configured to send websocket requests to a group of websocket-specific servers in a round-robin fashion based on pattern matching of the request ("/ws/*" requests get routed to the websocket target group). This target group could also be auto-scaled if needed. From my perspective, the big piece that's missing is some sort of messaging system that can broadcast messages to the cluster, like when session data changes (i.e. when a user logs out), in which case the websocket servers could react to those messages and do the right thing.

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

No branches or pull requests

4 participants