- Version: 1.40.0 (node-master)
- Platform: Windows 10
|
shutdown(tcp->socket, SD_SEND); |
On Windows, according to this comment, shutting down the transmit side of a socket should allow for an immediate graceful shutdown with closesocket - however this is not what I am observing. What I am observing is a TCP RST packet that goes away if I delay the shutdown to uv_tcp_endgame with close_socket = 0.
This can be easily reproduced with res.end() from Node - test/parallel/test-https-truncate.js is a very good example. The connection gets closed by a TCP RST by the server.
I wonder if Node should work around this issue or if it should be fixed in libuv. Normally, it is up to libuv to ensure that the socket is gracefully closed? Or is Node that should ensure that no reads are pending?
nodejs/node#35946
nodejs/node#35904
There is also a very similar issue on OSX for which I will create another issue when I am done digging, it looks like it is related to the default lingering.
libuv/src/win/tcp.c
Line 1450 in 11dd3b4
On Windows, according to this comment, shutting down the transmit side of a socket should allow for an immediate graceful shutdown with
closesocket- however this is not what I am observing. What I am observing is a TCP RST packet that goes away if I delay the shutdown touv_tcp_endgamewithclose_socket = 0.This can be easily reproduced with
res.end()from Node -test/parallel/test-https-truncate.jsis a very good example. The connection gets closed by a TCP RST by the server.I wonder if Node should work around this issue or if it should be fixed in libuv. Normally, it is up to libuv to ensure that the socket is gracefully closed? Or is Node that should ensure that no reads are pending?
nodejs/node#35946
nodejs/node#35904
There is also a very similar issue on OSX for which I will create another issue when I am done digging, it looks like it is related to the default lingering.