Make it possible to forcibly RST a net.Socket

[pimterry]

Is your feature request related to a problem? Please describe.

I'd like to forcibly reset a socket. Primarily for testing - I'm seeing unexpected RST packets in production, which is crashing my node HTTP proxy (my bug, that's fine), and I'd like to be able to write automated tests to ensure I've fixed correctly.

As far as I can tell it's only possible to cleanly close sockets with FIN, you can never intentionally RST.

Describe the solution you'd like

Something like socket.reset() would be great for my specific case, or alternatively low-level controls (e.g. the ability to set socket options as in the Python code below) would be equally useful.

Describe alternatives you've considered

For now, I've implemented this in Python instead. This Python 2.7.1 code is working for me:

import socket
import time
import struct

TCP_IP = '127.0.0.1'
TCP_PORT = 8000

# Connect to the server
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
s.connect((TCP_IP, TCP_PORT))

# Start an HTTP request
s.send("CONNECT example.com:80 HTTP/1.1\r\n\
Host: example.com\r\n\
\r\n\
GET / HTTP/1.1\r\n\
Host: example.com\r\n\
")
time.sleep(0.1)

# RST the socket without reading the response
s.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack('ii', 1, 0))
s.close()

Obviously I'd much prefer to test my Node server with JavaScript though, instead of having to bring in another language.

[sam-github]

Have you tried doing a socket.destroy()? It won't send a RST, but if more data arrives from the server after the .destroy(), that should trigger a RST response.

[pimterry]

Interesting! You're right, it's possible to make that work, but it ends up a little hacky. You can get close by translating the Python code and removing the delay, but you have a race to make sure you destroy after the request is sent but before the server response. To test I'm doing that with setTimeout(f, 0) straight after write(), which seems to win that race reliably, but it doesn't fill me with confidence.

I'd like to leave this open, as I would much prefer to be able to explicitly send the RST myself on demand rather than depending on this. It's easy to imagine similar situations where you don't know that there's imminent incoming data from the server, so destroy() wouldn't work. It's useful for me & very interesting though, thanks!

The resulting JS code for reference:

const net = require('net');

const socket = new net.Socket();
socket.connect(8000, "127.0.0.1", () => {
    socket.write(
`CONNECT example.com:80 HTTP/1.1
Host: example.com

GET / HTTP/1.1
Host: example.com
`
    );
    // If this is synchronous, it doesn't work
    // If it waits for write(), but no longer, it 50% works
    // Scheduling it immediately seems fairly reliable
    setTimeout(() => socket.destroy(), 0);
});

[sam-github]

Get rid of the setTimeout, its racy because setTimeout(..., 0) actually means setTimeout(..., 1) (check the docs), and there is no causal relationship between 1 ms of time passing and the data exchange with the server. Try socket.write('blah', () => socket.destroy());.

Btw, you describe this as hacky, but I'm not sure that is fair. Many things can cause an RST, but most of them are TCP protocol violations, and faking a bug in the OS TCP stack is probably not something node tests need to do.

The most common cause of an RST is exactly what you are doing: a socket is read-closed, but the peer continues to send data.

[pimterry]

Get rid of the setTimeout

Sadly I tested socket.write('blah', () => socket.destroy()) before, and it's significantly less reliable - works a little over half the time, talking to a local server. Just manual tests, nothing rigorous, but I'm yet to see the setTimeout approach fail at all.

faking a bug in the OS TCP stack is probably not something node tests need to do.

I'm not sure about the reasons, but I'm seeing a fair few unexpected RST packets from end-user clients, in real-world HTTP traffic. My product is an HTTP debugger (httptoolkit.tech) - effectively a local HTTP proxy for developers - this is coming from my end-user error reporting, with RST packets being sent by whatever people are connecting to that. For me it'd be really useful to able to precisely reproduce that behaviour in my tests.

[sam-github]

Any client that does write(socket, 'GET ...'); exit(); will cause RSTs when the server replies (exit implicitly closes all open sockets), you could be seeing variations of that.

[bnoordhuis]

See libuv/libuv#1991 (comment), the main problem is the interaction between SO_LINGER and shutdown().

[pimterry]

Since this suggestion, uv_tcp_close_reset is now available in libuv to do exactly this, for similar reasons. Presumably this could now presumably be implemented relatively easily by exposing that as a method on sockets.

I'd still find this useful. I'm in the same situation again right now of trying to test certain kinds of error reporting & handling with RST packets, and some cases are still not testable in node without a separate tool (Python).

[bnoordhuis]

@pimterry That's right. Pull request welcome, the places to look at are src/tcp_wrap.cc and lib/net.js. Adding the method to the former exposes it on socket._handle in the latter (but only when it's a wrapper around a TCP connection, of course.)

I'm inclined to leave out a forwarding method on tls.Socket for now.

[kolontsov]

I'd like to prepare PR, any suggestions on method name?

[bnoordhuis]

@kolontsov Just spitballing: net.Socket.prototype.reset()?

[kolontsov]

@bnoordhuis sounds great. ok.

[mmomtchev]

Any progress on that one?

[micromashor]

I've been investigating this for a while, although I'm a bit lost in the source code...

Will update if I make any progress