[API Proposal]: AddressFamily.Vsock, AddressFamily.HyperV

[fbrosseau]

Background and motivation

Proposal for AddressFamily.Vsock and AddressFamily.HyperV. I am not sure about the best letter casing for Vsock.

namespace System.Net.Sockets
{
    public enum AddressFamily
    {
+       Vsock = 40,
+       HyperV = 34,
    }
} 

As discussed in #58327, this current API proposal is only for the enums. EndPoint implementations for VSock and HyperV can be done in user code. This follows previous examples of API additions where only AddressFamily enum values were added and the rest is up to the users.

This proposal (at least the VSock part) unblocks the AF_VSOCK scenario, because right now the Unix SocketPAL refuses unknown AF values outright.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

Proposal for AddressFamily.Vsock and AddressFamily.HyperV. I am not sure about the best letter casing for Vsock.

namespace System.Net.Sockets
{
    public enum AddressFamily
    {
+       Vsock = 40,
+       HyperV = 34,
    }
} 

As discussed in #58327, this current API proposal is only for the enums. EndPoint implementations for VSock and HyperV can be done in user code. This follows previous examples of API additions where only AddressFamily enum values were added and the rest is up to the users.

This proposal (at least the VSock part) unblocks the AF_VSOCK scenario, because right now the Unix SocketPAL refuses unknown AF values outright.

Author:	fbrosseau
Assignees:	-
Labels:	api-suggestion, area-System.Net.Sockets, untriaged
Milestone:	-

[Wraith2]

If the unix pal allows you to pass through your own address family you don't need an enumerated value defined here to use the hyper-v socket. These options are niche enough that I'm not sure they need their own names. I have a working hyper-v endpoint in windows so I think the unblocking on unix is all that is needed.

[fbrosseau]

Yes indeed HyperV is not required to have working hyper-v sockets, it was suggested in the other issue that we add it anyway just as convenience, but if folks prefer to reduce the scope of this proposal that's fine either way.

[karelz]

Triage: In principle ok, but we have tried similar thing with netlink and failed -- @wfurt to link where we had to back it out. There were also conflicts with other AddressFamilies.
Let's not repeat similar mistakes when we take this.

We would like to see prototype first, before we bring it to API review. We expect that API review will be easy, if we are convinced we can implement it in a way we will not regret later.

[Wraith2]

Prototype of which part?

[antonfirsov]

@Wraith2 Vsock, since HyperV is just a trivial convenience API.

[Wraith2]

Ah, the bit I don't already have working. 😞

[antonfirsov]

@Wraith2 if you can link or copy here working code for HyperV, that would be also helpful for that part.

[Wraith2]

https://github.com/Wraith2/HyperVSockets it's enough to get a server process on the hyperv host and a client from a child within it connected using JsonRpc over a stream. There's windows specific stuff in there for looking up the client vitualmachine id which you'll have to provide an alternative for on linux but otherwise it should work if you can get the socket plumbed together.

[arontsang]

It would be interesting to keep any API changes open for other AddressFamily types.

I would really like to see support for XDP especially since we have memory/span. It would be very interesting to see what kind of raw packet performance we can get on dotnet.

[antonfirsov]

@arontsang do you have a particular application in mind for XDP, or is it just general interest?

Note that our datagram sockets suffer from heavy allocations even with UDP -- #30797. I don't see the point of introducing support for a high-perf protocol, without solving that problem first.

[arontsang]

@antonfirsov Just thought it would be fun. Although XDP would require us to design a datagram socket that works with buffer pools.

[antonfirsov]

Triage: moving this to future, since we don't believe we have the capacity to push through an API review on time for 7.0.

[mawelsh]

This probably didn't make it into 8, either. Getting support for the address families would do a lot to get a product I work on out of having to rely on other tunnels (Socat/HVC) to ride VSOCK. We're currently evaluating future feature development for additional services that will be coordinated over VSOCK via GRPC. Relying less on outside services would be ideal.

[antonfirsov]

@mawelsh you can instantiate a Socket from an existing SafeSocketHandle which you can you can create with P/Invoke, see #58327 (comment). Does this workaround work for you?