syscall: allow registration of new socket types for package net

[mdlayher]

Overview

At this time, there is no mechanism for socket types outside of the standard library to access the runtime network poller. This proposal, if accepted, would enable a resolution to issue #10565. This would enable packages outside of the standard library to take advantage of the runtime network poller, instead of implementing their own network polling mechanism.

Proposed Change

I propose adding a new API to package net which enables registration of arbitrary sockets for use with the runtime network poller. The design of this API is based upon a comment from @rsc found here: #11492 (comment).

It seems to me that the net package should just keep using (and providing) only FileConn but perhaps we can put a registration mechanism in package syscall to let clients register converters between sockaddrs and net.Addr for non-standard sockaddr types.

This is what I was able to come up with after a little bit of experimentation. Parameter list is to be determined, but this is what I was able to get working with my prototype on a Linux system. Efforts will be made to make this mechanism as generic and cross-platform friendly as possible, but it may not be implemented immediately on non-UNIX platforms. From what I can tell, syscall.Sockaddr does appear to be available on all platforms.

package net

// Registration mechanism, perhaps called in init() or main() when a
// socket is first initalized.
func RegisterSocket(
    family int,
    sockaddr syscall.Sockaddr,
    addr Addr,
    convertSockaddr func(syscall.Sockaddr) Addr,
    convertNetAddr func(Addr) syscall.Sockaddr,
)

// Generic net.Conn and net.PacketConn implementation which embeds the
// internal net.conn type.  Checks for registered socket hooks to determine
// validity of sent and received net.Addr implementations.
type SocketConn struct {
    conn
}

Example

Using a modified version of package net, I was able to gain access to the runtime network poller and
simplify my raw sockets package code to something like the following:

// Called in init() in package raw
net.RegisterSocket(
    syscall.AF_PACKET,
    &syscall.SockaddrLinklayer{},
    &Addr{},
    // internal conversion functions for syscall.SockaddrLinklayer <-> raw.Addr
    convertSockaddr,
    convertNetAddr,
)

sock, _ := syscall.Socket(syscall.AF_PACKET, syscall.SOCK_RAW, proto)
_ = syscall.Bind(sock, &syscall.SockaddrLinklayer{
    Protocol: pbe,
    Ifindex:  ifi.Index,
})
f := os.NewFile(uintptr(sock), "linklayer")
// c is type net.SocketConn, backed by raw socket (uses raw.Addr for addressing)
c := net.FilePacketConn(f)

Summary

The runtime network poller is an excellent mechanism, and enabling access to it will allow the future development of packages for raw ethernet sockets, netlink sockets, and other platform-specific socket types.

If this proposal is accepted, I'd happily seek guidance from @mikioh regarding creating the best possible API for this feature. In addition, this would enable me to contribute code from my raw ethernet socket package as a resolution to #8432.

Questions and comments appreciated, and thanks for your time.

/cc @rsc @mikioh

[rsc]

Hi,

Thanks for the work you've put in to figuring out what's possible. Can you
say more about why these are in package net instead of package syscall?
It's a bit of a non-starter for package net's API to expose so much (really
anything) from package syscall. If this were in syscall it would be more
palatable, and at first glance I don't see why it can't be. But I haven't
tried, so probably I'm missing something.

Thanks.
Russ

On Tue, Mar 29, 2016 at 2:18 PM Matt Layher notifications@github.com
wrote:

Overview

At this time, there is no mechanism for socket types outside of the
standard library to access the runtime network poller. This proposal, if
accepted, would enable a resolution to issue #10565
#10565. This would enable packages
outside of the standard library to take advantage of the runtime network
poller, instead of implementing their own network polling mechanism.

Proposed Change

I propose adding a new API to package net which enables registration of
arbitrary sockets for use with the runtime network poller. The design of
this API is based upon a comment from @rsc https://github.com/rsc found
here: #11492 (comment)
#11492 (comment).

It seems to me that the net package should just keep using (and providing)
only FileConn but perhaps we can put a registration mechanism in package
syscall to let clients register converters between sockaddrs and net.Addr
for non-standard sockaddr types.

This is what I was able to come up with after a little bit of
experimentation. Parameter list is to be determined, but this is what I was
able to get working with my prototype on a Linux system. Efforts will be
made to make this mechanism as generic and cross-platform friendly as
possible, but it may not be implemented immediately on non-UNIX platforms.
From what I can tell, syscall.Sockaddr does appear to be available on all
platforms.

package net
// Registration mechanism, perhaps called in init() or main() when a// socket is first initalized.func RegisterSocket(
family int,
sockaddr syscall.Sockaddr,
addr Addr,
convertSockaddr func(syscall.Sockaddr) Addr,
convertNetAddr func(Addr) syscall.Sockaddr,
)
// Generic net.Conn and net.PacketConn implementation which embeds the// internal net.conn type. Checks for registered socket hooks to determine// validity of sent and received net.Addr implementations.type SocketConn struct {
conn
}

Example

Using a modified version of package net, I was able to gain access to the
runtime network poller and
simplify my raw sockets package https://github.com/mdlayher/raw code to
something like the following:

// Called in init() in package raw
net.RegisterSocket(
syscall.AF_PACKET,
&syscall.SockaddrLinklayer{},
&Addr{},
// internal conversion functions for syscall.SockaddrLinklayer <-> raw.Addr
convertSockaddr,
convertNetAddr,
)
sock, _ := syscall.Socket(syscall.AF_PACKET, syscall.SOCK_RAW, proto)
_ = syscall.Bind(sock, &syscall.SockaddrLinklayer{
Protocol: pbe,
Ifindex: ifi.Index,
})f := os.NewFile(uintptr(sock), "linklayer")// c is type net.SocketConn, backed by raw socket (uses raw.Addr for addressing)c := net.FilePacketConn(f)

Summary

The runtime network poller is an excellent mechanism, and enabling access
to it will allow the future development of packages for raw ethernet
sockets, netlink sockets, and other platform-specific socket types.

If this proposal is accepted, I'd happily seek guidance from @mikioh
https://github.com/mikioh regarding creating the best possible API for
this feature.

Questions and comments appreciated, and thanks for your team.

/cc @rsc https://github.com/rsc @mikioh https://github.com/mikioh

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#15021

[mdlayher]

Hi Russ,

It appears to me that the runtime network poller functionality is exposed directly using the net.pollDesc type, which is then wrapped by net.netFD and net.conn. From what I can tell, it appears I'd have to duplicate or possibly move some code from package net to package syscall in order to enable accessing the runtime network poller there.

Specifically, I'm looking at net/fd_unix.go, and net/fd_poll_runtime.go. Is there an easier answer to this problem that I am not yet aware of?

Thanks for the quick reply, and I look forward to hearing back.

[rsc]

Your Example looks exactly as I think it should except for the fact that
the call is net.RegisterSocket instead of syscall.RegisterSocket. Can
RegisterSocket be moved into syscall? If not, why not? Thanks.

On Tue, Mar 29, 2016 at 3:08 PM Matt Layher notifications@github.com
wrote:

Hi Russ,

It appears to me that the runtime network poller functionality is exposed
directly using the net.pollDesc type, which is then wrapped by net.netFD
and net.conn. From what I can tell, it appears I'd have to duplicate or
possibly move some code from package net to package syscall in order to
enable accessing the runtime network poller there.

Specifically, I'm looking at net/fd_unix.go, and net/fd_poll_runtime.go.
Is there an easier answer to this problem that I am not yet aware of?

Thanks for the quick reply, and I look forward to hearing back.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#15021 (comment)

[mdlayher]

I am in favor of moving it to package syscall instead, but because much of the low-level functionality to access the runtime network poller already exists in package net, I am not sure how to best access the network poller from package syscall without duplicating code or moving it to syscall entirely.

Can you suggest a viable approach to solving this problem? Perhaps the low level runtime network poller code in net could be moved to an internal package that both net and syscall use to access it?

In summary, yes, I am in favor of creating syscall.RegisterSocket instead, but I am simply not sure how to access the runtime network poller from package syscall instead of package net, where it resides now, without code duplication.

EDIT: in addition, since net imports syscall, but I would need the net.Addr type in syscall, this would create a circular dependency. Any thoughts on how to resolve this issue as well?

[rsc]

Can you point me at the code you changed? Maybe that will help me see why
RegisterSocket cannot easily move into syscall. Thanks.

On Tue, Mar 29, 2016 at 3:45 PM Matt Layher notifications@github.com
wrote:

I am in favor of moving it to package syscall instead, but because much
of the low-level functionality to access the runtime network poller already
exists in package net, I am not sure how to best access the network
poller from package syscall without duplicating code or moving it to
syscall entirely.

Can you suggest a viable approach to solving this problem? Perhaps the low
level runtime network poller code in net could be moved to an internal
package that both net and syscall use to access it?

In summary, yes, I am in favor of creating syscall.RegisterSocket
instead, but I am simply not sure how to access the runtime network poller
from package syscall instead of package net, where it resides now,
without code duplication.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#15021 (comment)

[mdlayher]

Here's a link to the prototype I made to make this work. Obviously, it would need cleanup, proper locking, and probably should be wrapped in a type.

https://github.com/mdlayher/go/commit/2e7d77c17dbc830135ca35eb5617e073c8fc717b

[mdlayher]

Hey @rsc , did you get a chance to look at the prototype I created above? I'd love to hear your thoughts on it. Thanks for your time.

[mikioh]

@mdlayher,

I didn't have a look at your proposal/prototype carefully, and probably have no spare time for this feature (including #10565 opened by me) during Go 1.7 development cycle, but a bit. I think that the basic requirements for this feature look like the following:

1. Need to use the net package
   • As a glue to crypto/tls and net/http packages
2. Need to have a replacement for the syscall package
   • No use of types in the syscall package is mandatory because the syscall package is locked down and will be deprecated
   • The new package should provide a type that represents some sort of tuple known as a socket
   • The new package should provide flexibility for system adaptation not only for the existing kernels but for upcoming kernels that have fancy new network sockets
3. Need to have a replacement for the runtime package
   • This requirement might be optional, but having a way to use runtime-integrated network poller would be better
   • The new package should provide basic event notification mechanism on the runtime-integrated network poller

#10565 just covers R1, and perhaps your proposal too.

I'd like to see a design that fulfils the above requirements, at least R1 and R2. Otherwise, the design would be the source of trouble in future, like "I cannot achieve my goal because of the lack of R2 (or both R2 and R3)." I suppose that a typical use case would be either R1+R2 or R2+R3; the former is for people who want to use the existing read/write methods in the net package with new socket types and the latter is for people who want to use new read/write methods with new socket types.

Thoughts?

[mdlayher]

@mikioh Thanks for replying. Your requirements seem sound, but I wouldn't even know where to begin covering R2 and R3 (mine only covers R1).

Happy to help out if you have any sketches of a proposed API or something similar, but I don't have the knowledge of the internals of package runtime to create a public interface to the runtime network poller, etc.

[minux]

FTR, no one says the syscall package will be deprecated. It's just frozen. It should work fine for existing features and we even fixes bugs for existing features. We just won't add new features or make significant bugfixes (like BSD ABI broken changes.)

[mikioh]

FTR, https://golang.org/s/go1.4-syscall says that:

Note that we cannot clean up the existing syscall package to any meaningful extent because of the compatibility guarantee. We can freeze and, in effect, deprecate it, however.

not literally, but in effect.

[mikioh]

@mdlayher,

I think x/net repository is a good place for the new package implementing R2, because we can copy the package into src/vendor/golang.org/x/net/ and plumb it in the net package later.