We implement Node.js in Windows Azure to act as a persistent websocket endpoint (with Sock.js) for clients. Client messages from the websocket channel are routed as regular HTTP requests to backend services, with responses and other notifications going back up the same channel. After about a year, last month we began to switch to SSL as the main transport between the tiers.
It is with SSL/WSS did we infrequently encounter durations where Google Chrome would be unable to maintain the websocket connection, complaining "Received a broken close frame containing a reserved status code". The situation would correct itself in a few minutes, without us doing anything. After consulting the Sock.js folks, https://github.com/sockjs/sockjs-node/issues/125 When it happened again, I went through the process of decrypting the SSL traffic with wireshark and found that the websocket server is indeed sending a forbidden status code 1006 back to the client (RFC states it is supposed to be used for local status reporting, and not to be sent across the wire). However it is not known which layer of code is responsible for sending such a packet, and how to rectify this behaviour. The interesting thing was, after telling my colleague to revert back to plain http to communicate with the websocket server, while he could establish the socket connection, he would get reported errors from the socket layer because itself couldn't communicate with the backend. Looking at our websocket application log there were indeed trouble for our server acting as a client to the backend. So not only is client-to-websocket SSL failing, websocket-to-backend SSL is also failing. 2013-07-11 01:36:19.497 ERROR socket - [Error: 1744:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:openssl\ssl\s3_pkt.c:1234:SSL alert number 48 ] Error: 1744:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:openssl\ssl\s3_pkt.c:1234:SSL alert number 48 at CleartextStream._pusher (tls.js:656:24) at SlabBuffer.use (tls.js:199:18) at CleartextStream.CryptoStream._push (tls.js:483:33) at SecurePair.cycle (tls.js:880:20) at EncryptedStream.CryptoStream.write (tls.js:267:13) at Socket.ondata (stream.js:38:26) at Socket.EventEmitter.emit (events.js:96:17) at TCP.onread (net.js:397:14) And there were well over thirty port 443 TCP sockets pending to the backend TCP websocket_ip:56168 backend_ip:443 FIN_WAIT_2 Don't have enough experience with the networking protocols to piece together a picture that hints at the problem, and a solution. Anybody seen similar situations before? thanks, Aaron -- -- 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 --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
