Skip to content
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

add Netlink, Packet and Can to AddressFamily and ProtocolFamily enum #28636

Closed
wfurt opened this issue Feb 7, 2019 · 7 comments · Fixed by dotnet/corefx#37315
Closed

add Netlink, Packet and Can to AddressFamily and ProtocolFamily enum #28636

wfurt opened this issue Feb 7, 2019 · 7 comments · Fixed by dotnet/corefx#37315
Assignees
Labels
api-approved API was approved in API review, it can be implemented area-System.Net.Sockets
Milestone

Comments

@wfurt
Copy link
Member

wfurt commented Feb 7, 2019

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

@wfurt wfurt self-assigned this Feb 7, 2019
@stephentoub
Copy link
Member

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
Copy link
Member Author

wfurt commented Feb 7, 2019

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
Copy link
Member Author

wfurt commented Feb 7, 2019

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
Copy link
Member

krwq commented Apr 23, 2019

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
Copy link
Member

karelz commented Apr 24, 2019

@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
Copy link
Member

krwq commented Apr 24, 2019

I've updated the diff to be clearer

@krwq krwq changed the title add Netlink and Packet to AddressFamily and ProtocolFamily enum add Netlink, Packet and Can to AddressFamily and ProtocolFamily enum Apr 25, 2019
@terrajobst
Copy link
Member

terrajobst commented Apr 30, 2019

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.

@msftgits msftgits transferred this issue from dotnet/corefx Feb 1, 2020
@msftgits msftgits added this to the 3.0 milestone Feb 1, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-approved API was approved in API review, it can be implemented area-System.Net.Sockets
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants