-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inbound data lost when TLS connection resets. #149
Comments
Closing this – going to try and keep bugs that pertain to both joyent/node and iojs on the tracker they originate from! |
boingoing
added a commit
to boingoing/node
that referenced
this issue
Apr 6, 2017
napi: Fix test build break in test_function.cc
Closed
This was referenced Dec 1, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
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.
The text was updated successfully, but these errors were encountered: