Why SO_RCVTIMEO is inherited from listening socket to accepted socket?

Question

I couldn't find any documentation on this except from some Python documentation

18.1.4.2. Timeouts and the accept method

If getdefaulttimeout() is not None, sockets returned by the accept() method inherit that timeout. Otherwise, the behaviour depends on settings of the listening socket:

if the listening socket is in blocking mode or in timeout mode, the socket returned by accept() is in blocking mode;

if the listening socket is in non-blocking mode, whether the socket returned by accept() is in blocking or non-blocking mode is operating system-dependent. If you want to ensure cross-platform behaviour, it is recommended you manually override this setting.

I have read this [question]: Are socket options inherited across accept() from the listening socket? , I think in the end the verdict is still implementation defined. I guess testing on the platform is easier than reading the sources from each kernel.

Here it says clearly that timeout option is inherited. But on the manpage of accept(2), there's no mention of this. I found this quite shocking when I debugged some C++ code on one of my box ( Embedded Linux box). I expected the accepted socket not to inherit this option.

Where can I find a definitive answer to this question?

Answer 1

If this is a C question, rather than a Python question, I wouldn't draw any conclusions regarding SO_RCVTIMEO being inherited by accept(2) based on the Python docs. I think you may have misinterpreted the Python docs anyway, since they...

1. never explicitly mention the SO_RCVTIMEO option
2. never say the timeout value is inherited from the listening socket, but rather from the global timeout value set by setdefaulttimeout()

Looking at the source code for socketmodule.c, Python doesn't even use the SO_RCVTIMEO socket option. Instead, it stores the timeout value in its own internal representation of a socket object, and uses it in calls to select(2) and poll(2).

I suspect the rationale for Python's somewhat bizarre implementation is that it was designed to run on many platforms, some of which don't support the SO_RCVTIMEO option. The only reference SO_RCVTIMEO is on line 4773...

#ifdef SO_RCVTIMEO
PyModule_AddIntConstant(m, "SO_RCVTIMEO", SO_RCVTIMEO);
#endif

...where it's surrounded by pre-processor directives, in case SO_RCVTIMEO isn't defined on the platform on which it's compiled.

As for why the Python docs say...

...sockets returned by the accept() method inherit that timeout...

...that's because Python's internal implementation of accept() explicitly sets the internal timeout value of the new socket to the default timeout value on line 732...

s->sock_timeout = defaulttimeout;

As for the original question...

Where can I find a definitive answer to this question?

...I guess you'll have to hunt through the kernel source code until you find it, but it's probably simpler just to make no assumptions about what is inherited, and explicitly override any options you changed from their defaults on the parent socket FD on the new socket FD returned by accept(2).

Answer 2

The BSD Sockets API does this. The accepted socket inherits everything from the listening socket: receive buffer size, timeout, KEEPALIVE, close-on-exec. Some higher level APIs like Java then do more work to undo that, e.g.the read timeout.