We open a GUN instance successfully with the following TCP options {send_timeout, 30000} and {send_timeout_close, true}.
The options makes if the TCP stack can’t receive the sending packet and return a timeout, the socket will be closed.
Once the IP path has problem on the TCP connections, and the upper application sends the http request to the GUN instance continuously, the socket will closed finally.
It may be caused by the TCP sending window/buffer full. Then the OS close the socket will and send the TCP RST to peer(although it is impossible received by peer host).
However, the GUN instance is insensitive with this event. In the function gun_http2:request(), the returned value was not checked for gen_tcp:send().
The return value should be {error,timeout} first and {error,enotconn} after the socket is closed. I think GUN instance should exit for reason {error,enotconn} anyway.
essen
commented
2 years ago
We open a GUN instance successfully with the following TCP options {send_timeout, 30000} and {send_timeout_close, true}. The options makes if the TCP stack can’t receive the sending packet and return a timeout, the socket will be closed. Once the IP path has problem on the TCP connections, and the upper application sends the http request to the GUN instance continuously, the socket will closed finally. It may be caused by the TCP sending window/buffer full. Then the OS close the socket will and send the TCP RST to peer(although it is impossible received by peer host). However, the GUN instance is insensitive with this event. In the function gun_http2:request(), the returned value was not checked for gen_tcp:send(). The return value should be {error,timeout} first and {error,enotconn} after the socket is closed. I think GUN instance should exit for reason {error,enotconn} anyway.