Description
Duplicate of nodejs/node-v0.x-archive#8299
I am connecting to a remote server with a TLS connection, writing large amounts of data. When an error occurs the remote server writes one packet of data giving details of the error then immediately terminates the connection by sending RST.
The issue I have found is that if the remote server detects an error and closes the connection while my application is in the process of sending data, the connection will emit an EPIPE error on syscall "write" and immediately destroy the connection. Because the connection is destroyed, the data that is sent by the server is never read by node.js running the application and is simply lost.
I have discovered the following workaround which is far from ideal as it messes around with the internal machinery of node sockets, but works for me.
function destroyEPIPEFix(e) {
// When a write error occurs we miss the opportunity to
// read error data from the remote server. Delay the call to destroy
// to allow more data to be read.
var self = this;
var args = arguments;
var call = function () {
self._myDestroy.apply(self, args);
}
if (e && e.syscall == "write") {
setTimeout(call, 1000);
}
else {
call();
}
}
socket = tls.connect([...]);
socket._myDestroy = socket._destroy;
socket._destroy = destroyEPIPEFix;When I setup the connection I replace the _destroy method with one of my own making that delays the actual call to destroy by 1second when a write error occurs. 1second is actually much longer than it needs to be, but I am prepared to sacrifice the time to ensure the data is received.
Without the fix data is sometimes lost when a disconnection occurs, though not always. With the fix in place I have yet to lose any data, so the method is sound, but the implementation could use some work.
Unfortunately I have not been able to create a reliable test case so far. I have only observed the problem with a TLS connection but I would imagine it is a general TCP socket problem with node.