-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
TCP_KEEPIDLE value set by socket.setKeepAlive() is ignored on first keepalive probe #38445
Comments
cc @nodejs/platform-ibmi |
I tested this on Windows 10/x64 and Ubuntu/IBM POWER and things work correctly on those platforms. So, the problem does seem to be specific to IBM i. I also tested on IBM i 7.4 and found that the problem happens the same way there as on 7.2. Another interesting thing that I found is that the For example, if the IBM i system default TCP keepalive time is set to 5 minutes like this:
Then values like this are not ignored on the first keepalive probe:
But values like this are ignored on the first probe:
That is really strange, but in either case, setting TCP_KEEPIDLE before SO_KEEPALIVE seems to make things work correctly. If it helps, here is a simple socket server program that can be used to test the behavior. This code can be compiled with GCC in PASE for IBM i:
This code is in the working state, with FWIW, I also tested with a program like above, but running in the native IBM ILE environment, and found that the problem is the same. It seems that IBM i is just a bit quirky here... |
What steps will reproduce the bug?
I have only observed this problem on IBM i 7.2. I'm not sure if it happens on other platforms -- I haven't tried it.
Create a simple server program like this:
Then use a simple client program like this to connect to it while running a packet capture, so that you can see when TCP keepalive probes are sent:
The initial keepalive probe should be sent after the connection is idle for the amount of time passed to
socket.setKeepAlive()
, but instead the first probe is sent after the system-wide default time given by the value TCPKEEPALV on IBM i's CHGTCPA command. Subsequent keepalive probes are then sent on the correct interval.For example, if you set the system-wide default to 5 minutes using this command:
And then run the test above, the first keepalive will be sent after 5 minutes, and then subsequent keepalives will be sent after 1 minute.
Additional information
The problem relates to the order of the
setsockopt()
calls used to enable TCP keepalive and to set the idle time. I've found that, on IBM i, coding like this produces the problem I'm describing here:However, if TCP_KEEPIDLE is set first, then it works as expected:
Reversing the
setsockopt()
calls in this code would fix the problem:The text was updated successfully, but these errors were encountered: