ZUUL- websocket

[ctatineni]

Hello,

is there a way to communicate using web sockets and MQ with zuul?

[paskos]

I'm very interested in the answer to that question too

[NiteshKant]

Zuul 2 uses RxNetty which supports WebSockets. There is no plan to support MQ but PRs are always welcome :)

[thjaeckle]

What's the status on websocket support in zuul 2? Will it work out of the box because using rxnetty?

[NiteshKant]

Websockets support in Zuul can be interpreted in two ways, viz.,

1. Terminating Websockets as request-response: This would mean that Zuul is able to accept incoming WebSockets connections and by using some kind of request correlation executes its filter chain as a regular request-response.
2. Embracing full-duplex channels: This would mean revamping Zuul filters to embrace full-duplex interactions and be able to accept and produce any full-duplex protocol like WS, HTTP/2, etc.

1 above can be somewhat achieved with Zuul 2.0 although some changes to the filter processing will be required in terms of assumptions around using HTTP 1.1 semantics. 2 is a bigger change out of scope of zuul 2.x.

In Netflix once, 2.x is stable, we will be working on implementing Reactive Sockets with Zuul which is essentially case 2 above.

[jonfreedman]

Is there any ETA for a production release of 2.0 which could then be used in Spring Cloud? It seems the new spring-cloud-gateway project may replace Zuul but that is not production ready yet either.

[ermik]

I'm looking for an edge / elb solution for websockets — in my case I am not sending anything back to the client, so terminating into POST would be possible. But there is still no clear example of how to do that. Any advice?

[vklein]

Are there some news about websocket support in Zuul 2.1?

[artgon]

Yes, we are definitely planning to add it.

[MolaramSudaram]

@artgon Thank you very much. That sounds promising. Websocket support would push us forward with our IoT solution. Do you have an idea or a feeling when we can count on websocket support?

[cmdavinder]

Hi there, Just wondering if there is a ballpark date for Websockets suport? Thanks.

[artgon]

The functionality is there in the sample app right now, just waiting on documentation. @raksoras can provide more details.

[artgon]

Here's the wiki page: https://github.com/Netflix/zuul/wiki/Push-Messaging

[kasibkismath]

@artgon thanks for the wiki. However, I'm having issues while integrating it over SockJS-client and Zuul 2, where I've configured the websocket server's IP and Port for the api.ribbion.listOfServers.

Any working sample of the above kind would suffice or is there something I'm missing?

[raksoras]

@kasibkismath Are you trying to proxy WebSocket through Zuul to your background SockJS server? Proxying WebSockets is not yet supported in Zuul 2. Zuul can accepts WebSockets from frontend clients and send messages over those WebSockets to those client when triggered from the backend but it can't proxy WebSockets to another backend server yet. We may add that functionality in Zuul in future.

[kasibkismath]

@raksoras Yes, I'm trying to proxy my request from client to the backend server via Zuul using WebSocket. This particular statement is quite confusing - "Zuul can accepts WebSockets from frontend clients and send messages over those WebSockets to those client when triggered from the backend", can you please elaborate on this please?

[raksoras]

Current version of Zuul supports accepting WebSockets and holding them open so that your backend servers can push messages to your clients over those WebSockets in response to events happening in the backend. You can send (or "push") messages over the WebSocket by connecting to Zuul server on it's internal only "send-push-message" port. Take a looK at this package and specifically at this initialization. This functionality is somewhat similar to push services like APNS or GCM where the client maintains persistent ongoing connection with server and then server can push messages from the cloud to the client whenever it has something for the client.

What Zuul does NOT support today is generic WebSocket proxying. That is, accept a WebSocket connection at proxy layer and then relay or proxy frames back to a WebSocket on a backend service. It's something on our roadmap for Zuul but not implemented yet.

For more context you can see this presentation

Hope this helps.

[kasibkismath]

@raksoras thanks a lot for the detailed explanation and for the references.

[kasibkismath]

@raksoras I've tried to push the message to the default push port - 7008, from the WebSocket backend which is built in Spring Boot using the sendTo annotation which has the absolute uri for testing purposes.
However, I can't see the push message from the server to appear.

[raksoras]

What error/HTTP response code are you getting back from the server when you try to push the message to the client?

Are you trying with com.netflix.zuul.sample.SampleServerStartup included in the sample? If yes, make sure you are sending in a cookie named "userAuthCookie" with some customerId (for example, 1234) as its value when you open a WebSocket connection to Zuul server. Then you can connect to the same Zuul instance on port 7008 ("server_ip:7008/push") and do a POST with your message body and a special header "X-CUSTOMER_ID: 1234" to send the push message to that specific client. To have the push message successfully delivered, the customerId value in "userAuthCookie" in the original WebSocket connect request and the value of the header "X-CUSTOMER_ID" in the subsequent push message POST request must match.

Couple of things to keep in mind:

1. SampleServerStartup is there just to explain the concepts. The UserAuth used by it for push is very insecure. You shouldn't run it in production without replacing it with your own production-grade user auth implementation. You can easily do so by replacing SamplePushAuthHandler with your own subclass of PushAuthHandler.
2. The Sample server example works only in case of a single WebSocket server. If you run a cluster of WebSocket servers behind a load balancer then the in memory client connection registry used by the sample sever won't cut it. You need to replace it with a out of box registry that runs on it's own instance. Something like Redis is particularly suitable for the job of out of process client connection registry

[ashertoqeer]

@kasibkismath you can find a working demo here: Zuul 2 Push Messaging Sample I have written a blog post explaining how things are working.

[mohammadrafigh]

Do you still have a plan to add Websocket proxy?

[artgon]

Yes! It's on the roadmap for the coming 6-12 months.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.