Closed awolden closed 3 years ago
I am trying to solve the same issue and I am not successful so far. Your solution is interesting, but i wonder how it performs since you have to parse the headers in the master process...
I didn't do much performance comparison, I just did a load test to watch for dropped connections and issues like that.
Honestly, I made this change for a project I was working on, but I eventually walked away from clustering all together and ran each websocket process on a different port and used nginx to load balance between them. Anything performance dependent probably shouldn't be going through cluster.
I have tried your solution but it will fail back to XHR. You can see it at chrome console. All requests happened at XHR in tab network.
Sorry, I have totally missed this PR.
I totally agree that this is required, however I have a question/feedback. Do you think it may be easier to just use PROXY protocol?
This pull request is a proposed solution for reverse proxy support. It leaves all existing functionality in place with no effect whatsoever if you are not using the new proposed option:
proxyHeader
.This fixes issue #6 and #15 and it is heavily based on PR #20.
Logic
The basic logic is to parse the first packet on an incoming connection, read the IP header information, and load balance based on the header IP. The read packet is included in the load-balancing IPC message and is unshift'ed back onto the socket.
I included a basic proxy test and testing with websocket bench seems to indicate no major issues.
There were also some minor changes regarding the options object and I added some basic logic to support different types of balancing functions.
Example Usage