add Netlink, Packet and Can to AddressFamily and ProtocolFamily enum

[wfurt]

Both protocols are currently only supported on Linux but both provide interesting capabilities and been asked for by community.

AF_PACET sockets allow access to link-layer beyond limits of IP RAW sockets.

Netlink is used widely for various system communications (like route update notifications), can allow communication with kernel modules and support message multicasting.

I did some testing and existing socket functions seems to work well with new protocol families so changes to actually support them would be small.

Here is proposed change to public API:

 namespace System.Net.Sockets
 {
     public enum ProtocolFamily
     {
+        Netlink = AddressFamily.Netlink,
+        Packet = AddressFamily.Packet,
+        ControllerAreaNetwork = AddressFamily.ControllerAreaNetwork,
     }
     public enum AddressFamily
     {
+        Netlink = 30,           // Netlink protocol
+        Packet = 31,            // Linux Packet
+        ControllerAreaNetwork = 32, // Controller Area Network automotive bus protocol
     }
 }

Socket constructor takes protocol family but also protocol type and current enum is mostly IP oriented. Packet protocol uses Link layer type and can be possibly pretty large. For Netlink, there are several subgroups (https://en.wikipedia.org/wiki/Netlink) but it is also possible to define and use custom one via extensibility model.

Since this is specific to Linux and probably out of mainstream developers, I suggest for now that we do not enumerate all possibilities now and we let users of specific applications to cast int and provide direct value.
This could be re-visited later if implementation goes beyond Linux.

When one attempt to use them on Windows and OSX, existing code throws reasonable exception:

Windows

System.Net.Sockets.SocketException (10047): An address incompatible with the requested protocol was used
at System.Net.Sockets.Socket..ctor(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType)

OSX

System.Net.Sockets.SocketException (47): Address family not supported by protocol family
at System.Net.Sockets.Socket..ctor(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType)

cc: @karelz

[stephentoub]

What is the existing Max value in both AddressFamily and ProtocolFamily?

It seems like it's referring to the maximum value in the enums, which would have been a really unfortunate design to be made public, and changing it now is technically a breaking change, plus if anyone is using it in their code and has an existing binary compiled using it, that binary will retain the old value even after we change it. That said, I don't see a particularly good alternative; the main other one would be to simply not change Max and have it no longer be the max value.

However, is that actually what Max is? The docs are fairly non-descript, but state that it's the "MAX protocol" and "MAX address"... the capitalization there is confusing me. Is there some protocol and address family that's actually named "MAX"? If so, that'd be good news, as we wouldn't have to break anything... we just keep those values as they were.

[wfurt]

I did not find protocol MAX. However, I was looking for others like AddressFamily.Firefox and found https://stackoverflow.com/questions/1302494/what-does-addressfamily-firefox-refer-to-in-net-sockets

That has references to Winsock from 1996. My suspicion is that we took values verbatim from C header. But it seems like we never establish MAX as special value in C#. I think best option is to keep MAX as as and simply add new values to enum. Netlink=30 and PACET=31.

Also note, that this will not pop-up anyhow (in let say received message) unless explicitly asked for. One needs to create socket first and pass values in.

[wfurt]

More references to Winsock: https://searchcode.com/codesearch/view/10558954/

This instance has 3 more protocols and AF_MAX changed. However it is C #define, not even enum.

[krwq]

Adding CAN (Controller Area Network) to the list per offline conversation with @wfurt - this will be really useful in IoT scenarios.

This should be very simple additions but would allow us to utilize Socket for CAN bus scenarios without repeating sockets code and would also close couple of networking issues.

cc: @karelz for bar check for 3.0 (would be useful if we have shipped these enum values earlier so that we could utilize this in IoT in the next release without targeting preview bits)

[karelz]

@wfurt can you please update the top post with proper API proposal form? Something that is clear to anyone not familiar with the space (e.g. me ;)).

[krwq]

I've updated the diff to be clearer

[terrajobst]

Video

We should rename Can to ControllerAreaNetwork to avoid confusion with it being a word in English. Packet seems generic, but we can't think of a better, so it's fine.