TCP_KEEPALIVE, TCP_KEEPINTVL, and TCP_KEEPCNT Socket Options

[caleblloyd]

I am trying to set per-socket keepalive TCP timeouts on Linux and MacOS. The following named socket options are not exposed, however:

• SocketOptionName.TCP_KEEPALIVE
• SocketOptionName.TCP_KEEPINTVL
• SocketOptionName.TCP_KEEPCNT

When I try to add them using their POSIX codes, I get an exception:

  -------- System.Net.Sockets.SocketException : Operation not supported
       at System.Net.Sockets.Socket.SetSocketOption(SocketOptionLevel optionLevel, SocketOptionName optionName, Int32 optionValue, Boolean silent)
       at System.Net.Sockets.Socket.SetSocketOption(SocketOptionLevel optionLevel, SocketOptionName optionName, Int32 optionValue)

Here is the code I'm using to try to add them with POSIX codes:

if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux) || RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
{
	// Found these Socket Option Values at https://github.com/golang/go/search?utf8=%E2%9C%93&q=TCP_KEEPCNT
	// Linux/OSX takes time in seconds
	SocketOptionName tcpKeepIdle;
	SocketOptionName tcpKeepIntvl;
	SocketOptionName tcpKeepCnt;
	if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
	{
		tcpKeepIdle = (SocketOptionName)0x4; // TCP_KEEPIDLE
		tcpKeepIntvl = (SocketOptionName)0x5; // TCP_KEEPINTVL
		tcpKeepCnt = (SocketOptionName)0x6; // TCP_KEEPCNT
	}
	else
	{
		// TCP_KEEPALIVE option on OSX == TCP_KEEPIDLE on Linux
		// see https://www.winehq.org/pipermail/wine-devel/2015-July/108583.html
		tcpKeepIdle = (SocketOptionName)0x10; // TCP_KEEPALIVE
		tcpKeepIntvl = (SocketOptionName)0x101; // TCP_KEEPINTVL
		tcpKeepCnt = (SocketOptionName)0x102; // TCP_KEEPCNT
	}
	socket.SetSocketOption(SocketOptionLevel.Tcp, tcpKeepIdle, keepAliveTimeSeconds);
	socket.SetSocketOption(SocketOptionLevel.Tcp, tcpKeepIntvl, keepAliveIntervalSeconds);
	socket.SetSocketOption(SocketOptionLevel.Tcp, tcpKeepCnt, keepAliveCount);
}

[karelz]

Here's the code. I wonder if you know where the exception comes from. Is it propagated error code from native implementation?

cc: @Priya91 @stephentoub

[stephentoub]

I wonder if you know where the exception comes from

Each platform has its own values for these named options. As a result, the PAL layer expects a specific set of .NET-level values to be passed to SetSocketOption, which it then translates into the corresponding values for the platform:
https://github.com/dotnet/corefx/blob/master/src/Native/Unix/System.Native/pal_networking.cpp#L1866
If it doesn't recognize the input, then it doesn't know how to translate it, and reports it as being unsupported:
https://github.com/dotnet/corefx/blob/master/src/Native/Unix/System.Native/pal_networking.cpp#L2142-L2145

[CIPop]

@stephentoub This is more restrictive than .Net Framework which will try to set the option and return the OS-level error.
We could make the code pass through unknown PAL codes and properly document the X-Plat risk. We may also want to add the 3 enums to the public API.

/cc @karelz @davidsh

[stephentoub]

We could make the code pass through unknown PAL codes and properly document the X-Plat risk.

I'm fine with the idea of allowing other values to be set, but it's problematic because the value you want to set on a particular platform may be the same value as one of the .NET options, in which case we'll end up translating it to whatever value that .NET option maps to on that platform. Just as an example, the original post shows trying to pass TCP_KEEPIDLE, which on Linux is 0x4, which is the same value as SocketOptionName.ReuseAddress.

[caleblloyd]

Presently, all of the SetSocketOption methods in System.Net.Sockets.Socket take a SocketOptionName enum as their 2nd argument.

If arbitrary values were allowed to be set, SetSocketOption would probably need new overloads to provide a uint for the 2nd argument. These overloads could skip translation at the PAL layer completely.

It would be nice if the Public API contained all of the possible socket options across Windows, Linux, and Darwin. I think that there's probably quite a few besides for just these 3 that are missing in for Linux and Darwin. (I found a list of these codes here, TCP options are prefixed with TCP_ and Socket options are prefixed with SO_)

[CIPop]

If arbitrary values were allowed to be set, SetSocketOption would probably need new overloads to provide a uint for the 2nd argument. These overloads could skip translation at the PAL layer completely.

Makes sense. @stephentoub would you agree with @caleblloyd's solution above?
We could document the new override as being unsafe in X-Plat settings but it would unblock scenarios requiring platform-specific Sockets configuration.

/cc @karelz @davidsh

[stephentoub]

would you agree with @caleblloyd's solution above?

Yeah, I'd be ok with that, as long as the naming/signature made it very clear that this isn't just the equivalent to casting SocketOptionName to an int.

Another option would be to revisit the idea of having a library of P/Invokes for essentially all of POSIX, similar to Mono.Posix. Then if you were on Unix, you could pass the Socket's Handle to the setsockopt exposed there.

Those also aren't mutually exclusive.

[CIPop]

Having a platform-specific layer API sounds interesting as well - I wasn't aware of the discussions. @stephentoub is there a different issue regarding adding API similar to Mono.Posix that we can link to?

Meanwhile, since we all agreed on new API, I'll add the proper tags.
Adding the new overload accepting the uint shouldn't be very complicated work although it'll span across PAL, native code. The work will require following the new API process, testing and properly documenting the new overload.

[karelz]

Next step: We need formal API proposal

[vcsjones]

Well, for the proposal, I'm not sure TCP_KEEP_ALIVE is necessary as it's already there and it looks like the native bits translate the value correctly. https://github.com/dotnet/corefx/blob/bffef76f6af208e2042a2f27bc081ee908bb390b/src/System.Net.Sockets/src/System/Net/Sockets/SocketOptionName.cs#L21.

The other two are interesting on Windows. It's my understanding that they are not socket options, but rather control modes that get set with WSPIoctl and SIO_KEEPALIVE_VALS: https://msdn.microsoft.com/en-us/library/windows/desktop/dd877220(v=vs.85).aspx

The Win32 PAL seems to just take the SocketOptionName and pass it directly to setsocketopt: https://github.com/dotnet/corefx/blob/ec2a6190efa743ab600317f44d757433e44e859b/src/System.Net.Sockets/src/System/Net/Sockets/SocketPal.Windows.cs#L417

If my understanding is correct, then in the case of Windows, this isn't a simple matter of adding new members to the enumeration and updating the Unix / macOS PAL to translate the values correctly.

[luigiberrettini]

Isn’t this issue similar or superseded by dotnet/corefx#25040?

I think the public API should contain all possible socket options instead of allowing unsafe behavior, then a package like the Windows Compatibility Pack, could allow platform specific features.

[karelz]

Looks like that.
Closing as duplicate of dotnet/corefx#25040.