See #9503. We need a good compromise for both issues, and so need Windows experts.

I don't think you can have "if windows then just return c.fd" option, because it is not what (*conn).File documented to do. Why do you need access to Windows socket handle?

Alex

Excuse me for discuss, because we want to pass socket handle into external process for listening. For example, to implement graceful server, we often use fork/exec model.

In my case, I am passing it to some c compiled with cgo for additional
functionality
On Apr 7, 2015 12:36 AM, "mattn" notifications@github.com wrote:

Excuse me for discuss, because we want to pass socket handle into external
process for listening. For example, to implement graceful server, we often
use fork/exec model.

—
Reply to this email directly or view it on GitHub
#10350 (comment).

@vyrus001 there is no way to access original socket. If you need that functionality, you have to make copy of main Go repo and make whatever changes you want to net package.

@mattn I am not sure what you require, but have you tried implementing windows version of (*netFD).dup? Just use syscall.DuplicateHandle. Would that work for you?

Alex

@alexbrainman

https://msdn.microsoft.com/ja-jp/library/windows/desktop/ms724251%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

You should not use DuplicateHandle to duplicate handles to the following objects:

• I/O completion ports. No error is returned, but the duplicate handle cannot be used.
• Sockets. No error is returned, but the duplicate handle may not be recognized by Winsock at the target process. Also, using DuplicateHandle interferes with internal reference counting on the underlying object. To duplicate a socket handle, use the WSADuplicateSocket function.

Fair enough. Use WSADuplicateSocket instead. Would that work for you?

Alex

Works fine. (But not enough to do that I want)

Look this: https://github.com/mattn/gospel/blob/master/example/echo-server.go

This is not possible to build currently. For building, it need https://codereview.appspot.com/177590043/

This is fork/exec model server. This can replace executable without stop server with SIGHUP. This package is passing socket handle into child process on windows.

@mattn your old CL needs to be moved into Gerrit and made work on tip before we can discuss it.

Alex

https://go-review.googlesource.com/#/c/8683/

CL https://golang.org/cl/8683 mentions this issue.

Gah, I just ran into this as well:
I actually need to do exactly what MSDN says not to do (DuplidateHandle) so I can pass the fd to an "dumb" process. Unfortunately WSADuplicateSocket requires both processes to be in cooperation in order to pass off a special structure. Basically, I want to do this: https://github.com/vrcsix/synchronet/blob/93b01c55b3102ebc3c4f4793c3a45b8c13d0dc2a/src/sbbs3/main.cpp#L3085

If there is no way to get a underlying socket fd, I'm probably at a dead end golang-wise :(

This issue might be unfixable because of the architectural differences between Unix-variants and Windows. One good news is that Go 1.12 supports #24331; you may use os.File.SyscallConn instead of File method of net.{TCP,UDP,IP}Conn.

The purpose of this issue is to get the handle of a *net.TCPConn.
I think this issue was already fixed by (*net.TCPConn).SyscallConn
https://golang.org/pkg/net/#TCPConn.SyscallConn

The FileConn and (*os.File).Fd methods have other side effects(dup, blocking mode), so I think it's hardly useful now.

@crvv,

The purpose of the File method is not only for tweaking/crafting the underlying socket but for passing a cloned descriptor pointing to the same underlying socket to external processes.

I can see that it would not be fixable with the current API (due to dupe guarantees/etc.), but certainly would be nice and useful for many reasons. It's a bit of a shame that the API kind of tosses Windows out the the uh... window here.

@mikioh
The purpose of @vyrus001 is to pass the handle to C code.
That can be done via SyscallConn, like

package main

/*
#cgo LDFLAGS: -lWs2_32
#include <stdio.h>
#include <Winsock.h>

void get_listen_addr(SOCKET s) {
    struct sockaddr_in name;
    int namelen = sizeof(name);

    if (getsockname(s, (struct sockaddr*)&name, &namelen)) {
        printf("failed %d\n", WSAGetLastError());
        return;
    }
    printf("%hhu.%hhu.%hhu.%hhu:%hu\n",
        name.sin_addr.S_un.S_un_b.s_b1,
        name.sin_addr.S_un.S_un_b.s_b2,
        name.sin_addr.S_un.S_un_b.s_b3,
        name.sin_addr.S_un.S_un_b.s_b4,
        ntohs(name.sin_port));
}
*/
import "C"
import "net"

func main() {
        listener, err := net.Listen("tcp4", "127.0.0.88:0")
        if err != nil {
                panic(err)
        }
        defer listener.Close()
        rawConn, err := listener.(*net.TCPListener).SyscallConn()
        if err != nil {
                panic(err)
        }
        fdCh := make(chan uintptr, 1)
        err = rawConn.Control(func(fd uintptr) {
                fdCh <- fd
        })
        if err != nil {
                panic(err)
        }
        fd := <-fdCh
        // You can do anything with the fd now
        println(listener.Addr().String())
        C.get_listen_addr(C.SOCKET(fd))
}

The handle can also be passed to external processes with os.NewFile and os.ProcAttr.Files.
The document of syscall.RawConn says

The file descriptor fd is guaranteed to remain valid while f executes but not after f returns.

But this approach is not worse than (*os.File).Fd() method.

Any progress on this issue?
I've written a function to emulate the "socketpair" syscall under unix, which I'd like to use to communicate between parent process and child process through os.StartProcess(), unfortunately I got an error: "not supported in windows". And I found the (*net.TCPConn).File() method is not implemented under Windows.

func SocketPair() (pair [2]*os.File, err error) {
	door, err := net.Listen("tcp", "127.0.0.1:0")
	if err != nil {
		return
	}
	defer door.Close()
	this, err := net.Dial("tcp", door.Addr().String())
	if err != nil {
		return
	}
	defer this.Close()
	that, err := door.(*net.TCPListener).AcceptTCP()
	if err != nil {
		return
	}
	defer that.Close()

	pair[0], err = this.(*net.TCPConn).File()
	if err != nil {
		return
	}
	pair[1], err = that.File()
	if err != nil {
		pair[0].Close()
	}
	return
}

So is there any workaround?

@mikioh The purpose of @vyrus001 is to pass the handle to C code. That can be done via SyscallConn, like

package main

/*
#cgo LDFLAGS: -lWs2_32
#include <stdio.h>
#include <Winsock.h>

void get_listen_addr(SOCKET s) {
    struct sockaddr_in name;
    int namelen = sizeof(name);

    if (getsockname(s, (struct sockaddr*)&name, &namelen)) {
        printf("failed %d\n", WSAGetLastError());
        return;
    }
    printf("%hhu.%hhu.%hhu.%hhu:%hu\n",
        name.sin_addr.S_un.S_un_b.s_b1,
        name.sin_addr.S_un.S_un_b.s_b2,
        name.sin_addr.S_un.S_un_b.s_b3,
        name.sin_addr.S_un.S_un_b.s_b4,
        ntohs(name.sin_port));
}
*/
import "C"
import "net"

func main() {
        listener, err := net.Listen("tcp4", "127.0.0.88:0")
        if err != nil {
                panic(err)
        }
        defer listener.Close()
        rawConn, err := listener.(*net.TCPListener).SyscallConn()
        if err != nil {
                panic(err)
        }
        fdCh := make(chan uintptr, 1)
        err = rawConn.Control(func(fd uintptr) {
                fdCh <- fd
        })
        if err != nil {
                panic(err)
        }
        fd := <-fdCh
        // You can do anything with the fd now
        println(listener.Addr().String())
        C.get_listen_addr(C.SOCKET(fd))
}

The handle can also be passed to external processes with os.NewFile and os.ProcAttr.Files. The document of syscall.RawConn says

The file descriptor fd is guaranteed to remain valid while f executes but not after f returns.

But this approach is not worse than (*os.File).Fd() method.

As the documentation says, when the f function returns, won't the obtained handle be invalidated?

No, the handle won't be invalidated.
The handle will be invalidated when it is closed. If Conn.Close is called on another goroutine, the socket won't be closed until the f function returns.
This is the meaning of the documentation and it is also the reason why Fd uses dup. So I said "is not worse than Fd method".

The problem here is not how to get the handle, which is solved by SyscallConn.
The problem is Close may not work correctly if the handle/fd is passed to user code.
The handle can also be closed by the garbage collector.

This is the same problem as the dangling pointer.
I don't think Go stdlib can solve this problem. It is the user's responsibility to write the correct code at this situation.

No, the handle won't be invalidated. The handle will be invalidated when it is closed. If Conn.Close is called on another goroutine, the socket won't be closed until the f function returns. This is the meaning of the documentation and it is also the reason why Fd uses dup. So I said "is not worse than Fd method".

Thank you very much, I now use the go coroutine and chan to make f blocked, so that the handle is always valid. When the user code closes, f is returned through the synchronized chan, the code is similar to the following, I don't know if this is the best practice in this way?

func (s *struct) getFd() {
	fdCh := make(chan uintptr, 1)
	s.syncClose = make(chan int)
	go func() {
		s.rawConn.Control(func(fd uintptr) {
			fdCh <- fd
			<-s.syncClose
		})
	}()
	s.fd = <-fdCh
}
func (s *struct) close() error {
	s.syncClose <- 1
}