If a client is connected to server1 and server1 goes down, it loses its WebSocket connection, but any new connections would automatically go to server2. I don't think there's anything which would automatically keep the WebSocket connection from client to proxy, and redirect the traffic on the back-end (it's not actually possible without ridiculous amounts of buffering - if you were in the middle of sending a very large fragmented packet, it would require the proxy to buffer the entire thing, or just drop it but then you're effectively dealing with packet loss, and madness lies in that direction).
In our case, in the event of a crash, the client gets a WebSocket disconnect event, and we just reconnect (actually just refresh the page, but could do a reconnect). With any TCP-level load balancing, connections go to arbitrary servers, so if you need to correlate multiple requests to the same user, then, yes you need to use something external to share information between the servers. That being said, a single WebSocket connection is guaranteed to send all packets to the same server, so if all of your stateful application logic is done over WebSockets, there's no need for any external tracking. You can also somewhat work around this by configuring the HAProxy to load balance based on source IP address, or if HTTPS-only, based on the client's SSL ID peeked out of the SSL stream. We went the route of having virtually everything stateful done over the WebSocket connection, with a small amount of the usual externally stored session information so that when a POST/file upload goes to a different server, it can correlate it with the appropriate user. On Monday, July 30, 2012 2:54:47 AM UTC-7, hd nguyen wrote: > > @Jimb Esser: with that configuration, eg a client first connect to socket > server1, everything is ok, but server1 is crashed, so the system will > redirect and make new connection to socket at server2 automatically, right? > > Is everything transparent to developer and end user or we need to handle > it by code (using Redis to store client's information....)? > > Regards, > > On Mon, Jul 30, 2012 at 2:17 PM, hd nguyen <[email protected]> wrote: > >> @Jimb: thank you so much for your useful comment :) >> >> >> On Sat, Jul 28, 2012 at 2:05 AM, Jimb Esser wrote: >> >>> We're using HAProxy+stud+WebSockets/SecureWebSockets. When I was doing >>> some performance testing, stud was notably faster than all of the other >>> alternatives for the latency/CPU usage of SSL termination (this was on node >>> 0.4.x at the time, but stud was about 2x as fast as node or nginx). >>> >>> HAProxy is fine, but if you want to put your SSL termination behind your >>> load balancer (otherwise quickly that becomes your bottleneck if all of >>> your traffic is https), you need to run it in TCP mode. HAProxy for HTTP >>> (non-secure) seemed to work fine for WebSockets even when not in TCP-mode. >>> >>> If in TCP mode, and you want IP address of your connections, it's a bit >>> of work since you can't do header re-writing. Need to have HAProxy >>> configured with send-proxy, and stud with --read-proxy and --write-proxy or >>> --proxy-proxy (look in stud's pull requests for these), and node needs to >>> be patched with the ability to read the proxy line before starting HTTP >>> parsing (requires building node yourself). >>> >>> Jimb Esser >>> Cloud Party, Inc >>> >>> >>> On Friday, July 27, 2012 12:48:33 AM UTC-7, hd nguyen wrote: >>> >>>> Thanks guys, >>>> >>>> As Arnout said, Arnout we should have 2 options for this case: HAproxy >>>> or node-http-proxy module. >>>> >>>> Anyone can help me figure out which option is the better choice for >>>> enterprise app? >>>> node-http-proxy is being used by Nodejitsu, but cannot find a >>>> trustworthy site/source using HAproxy+websocket/socket.IO ?! >>>> On Fri, Jul 27, 2012 at 2:36 PM, Arnout Kazemier wrote: >>>> >>>>> There is nothing wrong with using HAproxy to load balance WebSocket / >>>>> Socket.IO requests. It works perfectly fine >>>>> and is a proven and well established technology stack. You just need >>>>> to make sure that you run it TCP mode.. Here >>>>> is some example configuration on working with Socket.IO + HAProxy + >>>>> stud; https://github.com/dvv/**farm <https://github.com/dvv/farm> >>>>> >>>>> Nginx will probably not work because it doesn't support HTTP 1.1 for >>>>> upstream proxies. If you don't want to complicate >>>>> your stack with different technologies, you can indeed use the >>>>> excellent Nodejitsu HTTP proxy. https://github.com/** >>>>> nodejitsu/node-http-proxy<https://github.com/nodejitsu/node-http-proxy> >>>>> >>>>> On Friday 27 July 2012 at 08:30, hd nguyen wrote: >>>>> >>>>> So I can understand that till now this combination is not working well? >>>>> >>>>> On Fri, Jul 27, 2012 at 1:08 PM, dvbportal wrote: >>>>> >>>>> In the past such setups didn't work. Maybe the latest versions are >>>>> doing better. A tested variant though is Nodejitsu's proxy. It can do >>>>> websockets and load balance with a bit additional code. >>>>> >>>>> - Hans >>>>> >>>>> -- >>>>> Nguyen Hai Duy >>>>> Mobile : 0914 72 1900 >>>>> Yahoo: nguyenhd_lucky >>>>> >>>>> >>>>> >>>>> -- >>>> Nguyen Hai Duy >>>> Mobile : 0914 72 1900 >>>> Yahoo: nguyenhd_lucky >>>> >>> -- >>> >>> >> -- >> Nguyen Hai Duy >> Mobile : 0914 72 1900 >> Yahoo: nguyenhd_lucky >> > > > > -- > Nguyen Hai Duy > Mobile : 0914 72 1900 > Yahoo: nguyenhd_lucky > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
