Proposal: x/net/socket, vendor/golang.org/x/net/socket: new package to register socket types with package net

[mdlayher]

As of now, there is still no way to access the runtime network poller with custom socket types. As a follow up to #15021, I'd like to try implementing a new package in x/net that contains a Socket type which can later be plumbed into package net, enabling access to the runtime network poller.

The basis of this proposal lies in a comment by @mikioh here: #15021 (comment)

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

I have not found a name I'm happy with for this package, but for now, let's refer to it as x/net/socket. The API could look something like the following:

package socket

// Custom socket types that can be registered with this package, identified
// by address family.
type Socket interface {
    Family() int
    Addr() Addr
    ToAddr(sa Sockaddr) Addr
    ToSockaddr(addr Addr) Sockaddr
}

// A syscall.Sockaddr, without importing syscall.
// Not sure if there is a way around this.  Maybe importing syscall for
// syscall.Sockaddr is okay, since this isn't changing package syscall?
type Sockaddr interface{}

// Duplication of net.Addr.  Can't import net directly because this package
// could be vendored into the standard library and used by net later.
type Addr interface {
    Network() string // name of the network
    String() string  // string form of address
}

// Registers a Socket into the package.
func Register(s Socket)

// Retrieves all Sockets registered into the package.  Can be used
// by net later to handle unknown address families.
func Sockets() []Socket

If this proposal is on the right track, I'd be happy to start working on the new package. In a later proposal, we can discuss the mechanism for plumbing it into package net.

Thanks for your time! Let me know if there are any unresolved questions.

/cc @mikioh

[adg]

Hi, thanks for submitting a proposal.

My immediate question is: why? You lead by saying there is "no way to access the runtime network poller with custom socket types," but then don't provide any explanation as to why this is desirable. The rationale might be obvious to some, but it's not to me. Can you provide some background as to why and how you want to use the proposed package?

Thanks!

[mdlayher]

The intent is to enable packages which live outside the standard library to gain access to the runtime network poller, and to avoid having to duplicate the functionality of the poller externally.

For example, I've written an ethernet sockets package, but because I can't use the network poller to determine when the socket has data available, my options are to either:

• not support timeouts at all (blocking socket I/O)
• run in a loop and keep checking for EAGAIN
• implement custom socket polling using platform-specific mechanisms like epoll, kqueue, etc.

Ideally, third party libraries should be able to create sockets which can take advantage of Go's network poller. Also see issue #10565.

[mdlayher]

Ping, @mikioh .

[bradfitz]

Is this a dup of #15021? Sure looks like it.

[adg]

Ping?

[mikioh]

#15021 is a sibling issue but different one. We need two types of hooks from the standard library. This issue is for hooks of a tuple facility of connection endpoint, and #15021 is for hooks of I/O event multiplexing on connection endpoints.

FWIW, I made a rough cut of x/net/socket package that looks a drop-in replacement of socket-related stuff in the existing syscall package this summer. It worked well on Unix variants by vendoring/replumbing. I'll send it to review once the traffic of golang-codereviews calms down.

[bradfitz]

@mikioh, I have no clue what a "tuple facility of connection endpoint" is, and I don't think anybody else can distinguish this bug from #15021 (or #10565) for that matter, so I'm going to close this bug as a dup of #15021.

Conversation can continue in #15021.