I use quic transmission，but sometimes quic will close all network connections.

[s1377427321]

source code：
ts, err := c.conn.AcceptStream()

i detecte error
InternalError: read udp4 0.0.0.0:55289: wsarecvfrom: The connection has been broken due to keep-alive activity detecting a failure while the operation was in progress

[anacrolix]

Thanks for spotting this. This is a common bug around UDP use with Go on Windows. We should move this issue to either the QUIC transport wrapper, or report it directly to the Go QUIC implementation if the mistake is there. @marten-seemann can you assist?

[marten-seemann]

We had an issue for this in quic-go: quic-go/quic-go#1737. Being pretty inexperienced with Windows, I assumed that wsarecvfrom was some an error code of another library wrapped around quic-go, which is why I closed this issue without action, and unfortunately never got any response.

I'm running all unit and some of the integration tests on AppVeyor on Windows, and everything seems to work fine there. I'll need some guidance in how to reproduce this issue.

[anacrolix]

I think the following could help:

• https://github.com/anacrolix/go-libutp/blob/83b91757267c217d24927a1cec0a57f2ea75a797/socket.go#L141
• UDP errors on Windows anacrolix/torrent#83

[Stebalien]

@djdv, any ideas?

[djdv]

Disclaimer: I lack experience with UDP on Windows. Mostly familiar with TCP and Named Pipe connections.

This appears to be
WSAECONNRESET (10052)
https://docs.microsoft.com/en-us/windows/desktop/WinSock/windows-sockets-error-codes-2
Edit: removed additional text, I mixed up WSAECONNRESET and WSAENETRESET 👀

I'm lacking context here though. During an accept or send, what's probably happening is that data was buffered, the remote host became unreachable, and the next read call errors. Whatever is wrapping these operations is then picking up on this and closing the socket. But I'm not sure the inner workings here or the dependency chain.

With context from @anacrolix it looks like we can receive innocuous or potentially incorrect (library fault) errors from Read() that are probably tripping something to close the socket prematurely. In the linked torrent issue it seems appropriate to disregard the error entirely or adjust the buffers (depending on what error was actually received.

My best guess is that if these errors aren't already exposed, we need to explode them out and switch on them using
https://docs.microsoft.com/en-us/windows/desktop/api/winsock2/nf-winsock2-wsarecvfrom
as a reference for what is and isn't fatal.

[anacrolix]

With context from @anacrolix it looks like we can receive innocuous or potentially incorrect (library fault) errors from Read() that are probably tripping something to close the socket prematurely. In the linked torrent issue it seems appropriate to disregard the error entirely or adjust the buffers (depending on what error was actually received.

Yep, spot on.

My best guess is that if these errors aren't already exposed, we need to explode them out and switch on them

I'd love to see how you solve that. It's difficult to pin down specific errors in Go due to the very loose typing inside the error interface.

[djdv]

I'd love to see how you solve that. It's difficult to pin down specific errors in Go due to the very loose typing inside the error interface.

It's true. Go can make this pretty ugly if the libs don't export error variables for us.
Typically you have to do some digging to find the origin of the error.

In this case it likely originates from pkg/net and is likely a net.OpError.
If we had a reproducible case we could easily just use Go itself to tell us the underlying type with a simple fmt call fmt.Printf("%T %#v\n", err, err).

Once we know the source and concrete type of the error, it's just a matter of unwrapping it. It's messy but likely necessary if the abstractions don't already provide a way to do something like err == somelib.ErrUDPTTL

err := ambiguousErr()
if netErr, ok := err.(net.OpError); ok {
    if netErr.Temporary() {
        // drop err;  break|return
    }
    log.Errorf("Fatal net error: {%T}%#v", netErr.Err, netErr.Err)
}
log.Errorf("Unexpected/Unhandled error: {%T}%#v", err, err)

Depending on the source of the error and the level of control needed, you could repeat the pattern to continue unwrapping. In the case of a net.OpError you could get the underlying error from the struct which is likely in itself a syscall.Errno or a wrapper of it.

...
if netErr.Temporary() {
    ...
}
if platformErr, ok := netErr.Err.(syscall.Errno); ok {
    if platformErr == SomeConst {
        // drop err;  break|return
    }
}

Edit: no more code changes 🤞

[djdv]

It's looking like the error is generated here:
https://golang.org/src/net/fd_windows.go#L160

func (fd *netFD) readFrom(buf []byte) (int, syscall.Sockaddr, error) {
	n, sa, err := fd.pfd.ReadFrom(buf)
	runtime.KeepAlive(fd)
	return n, sa, wrapSyscallError("wsarecvfrom", err)
}

https://golang.org/src/net/error_posix.go

If needed you could insert this into one of them to see the whole call stack and see who's generating this error when it happens.

var i int
for {
	pc, fn, line, ok := runtime.Caller(i)
	if !ok {
		break
	}
	fmt.Printf("[%d] %s[%s:%d]\n", i, runtime.FuncForPC(pc).Name(), fn, line)
	i++
}

[Stebalien]

Closing in favor of quic-go/quic-go#1737.