isapir / lucee-websocket

Enables server WebSockets for Lucee via JSR-356 compliant servlet containers (e.g. Tomcat 8, Jetty 9.1, etc.)
GNU Lesser General Public License v2.1
17 stars 6 forks source link

Pub/Sub Features #15

Open sosensible opened 6 years ago

sosensible commented 6 years ago

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 commented 6 years ago

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

sosensible commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

dawesi commented 5 years ago

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

redtopia commented 5 years ago

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.