When not handling errors on the socket connection, long-lived requests (for example WebSocket connections) which eventually have a TCP timeout (for example, if the client has its network cable disconnected) will eventually cause an unhandled socket error which kills bouncy.
This change handles those errors. It also allows setting an option onConnectionError so that the code invoking bouncy can print a message when a connection error occurs. In order to do this, I stick the callback into opts and pass opts to the handler, which as a side-effect lets you pass the callback as an option, which I think is cleaner.
If you hate this approach, I can revert the opts.onConnectionError part of this change. Installing an error handler on the socket is pretty critical, though - otherwise we were seeing frequent bouncer death when using websockets.
Handle socket errors, add onConnectionError opt.
I'm seeing similar issues with putting bouncy in front of socket.io projects where the bouncy instance dies.
Passing onConnectionError is a bad interface. Use event emitters instead.
What does this solve that you can't already do with bouncy(...).on('error', fn)? bouncy() just returns the net.Server object directly.