Add the TCP KeepAlive APIs to .NET Standard

[alexkeh]

These 3 options are not in .netstandard 2.1 right now, do you have a plan to add them into netstandard?

• TcpKeepAliveInterval
• TcpKeepAliveRetryCount
• TcpKeepAliveCount

Originally posted by @kerryjiang in https://github.com/dotnet/runtime/issues/24041#issuecomment-554154891

[juliusfriedman]

See also: https://github.com/dotnet/runtime/issues/39566

You can do this yourself with little interop around setsocketopt and getsocketopt

[kerryjiang]

Actually you can set it by a delegate in the entrance application (netcoreapp).

[ScotMac]

@juliusfriedman obviously we would prefer a fully .NET solution, instead of having to do platform specific interop. In fact, platform independence was the point of adding the new APIs in the first place. They just didn't get supported by NetStandard (only .NETCoreApp).

@kerryjiang can you please expand on your proposal?

[kerryjiang]

@ScotMac

// in netcoreapp3.0
// register Action<Socket> into the services
.ConfigureSocketOptions(socket =>
{
     socket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.TcpKeepAliveTime, 10);
     socket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.TcpKeepAliveInterval, 5);
     socket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.TcpKeepAliveRetryCount, 7);
})

// in netstandard
// _socketOptionsSetter is Action<Socket>
_socketOptionsSetter(socket);

[ScotMac]

Sorry @kerryjiang , I dont get it. So, for a netStandard library, you register your. ConfigureSocketOptions "Action"? Can't, since netStandard can not reference the new keepalive enums (eg TcpKeepAliveTime), because they were not added to netStandard (hence the point of this issue).

[kerryjiang]

@ScotMac

SocketOptionName.TcpKeepAliveTime is used in netcoreapp(3.0 or above).

[ScotMac]

@kerryjiang

RIGHT. But not NetStandard, which is the point of this issue. If you target NetStandard (any version), it is not available.

[kerryjiang]

@ScotMac

Project A (netcoreapp): the action is defined in the netcoreapp project a which is the entrance project of the application; Project B (netstandard): the action is used in this project to apply options to the socket;

[ScotMac]

@kerryjiang

We are a NetStandard library. We have no control over the "entrance project" or the "application". Many thousands of different "applications" will utilize our library.

Again, we need the new APIs to be part of NetStandard.

[kerryjiang]

@ScotMac What I mentioned is just a workaround. What we can do for now is to just expose the api and give a chance to the entrance project to do the magic.

I wish the APIs exist in the netstandard as well.

[ScotMac]

@kerryjiang

In terms of a workaround, a better solution is to check if the application using our library is using NetCoreApp 3+, and if so, then use "reflection" to dynamically load the System.Net.Sockets.dll, use "reflection" to load from that dll the the two different overloads of "socket.SetSocketOption()" AND load the values for the necessary enums, and then Method.Invoke() the calls to the SetSocketOptions()'s.

However, forcing every NetStandard library to do the above is obviously not the best way to encourage developers.

[terrajobst]

Closing as not planned, as .NET Standard is considered complete.