UDP errors on Windows #83
Comments
|
Thanks for this. I don't do testing on Windows. This would occur if the UDP connection in use had been closed. It may be closed in some circumstances if there's an unexpected error in either DHT or uTP. Are you able to get the first few messages before this avalanche of "use of closed network connection"? The reason should be there. In the meanwhile I'll try to suppress the "use of closed network connection" error message as it's not useful. |
|
I've done some more poking. It's very likely that there's an unexpected read error from Windows in the uTP package, possibly a temporary error that needs to be handled, that triggers the uTP socket to be destroyed. This socket is shared with DHT, which doesn't expect this to happen. Let me know if you can find that first error message. |
|
What version of Go are you using? |
|
This is the info about my system. I will try to get the first UDP error and will let you know. |
|
Is that it? |
|
https://lists.freedesktop.org/archives/nice/2014-October/000968.html The error seems to be Windows specific and related to the TTL value set for the UDP socket. On my machinge (Windows 7) TTL is 64. I will try to modify the TTL (if Go allows it) for the UDP socket and will let you know how it goes. |
|
I did some debugging. It's not related to TTL at all. Here you're creating the udp listening socket: func NewSocket(network, addr string) (s *Socket, err error) {
if network == "" {
network = "udp"
}
pc, err := listenPacket(network, addr)
if err != nil {
return
}
// aded code
ptrVal := reflect.ValueOf(pc)
//fmt.Println(ptrVal)
val := reflect.Indirect(ptrVal)
//fmt.Println(val)
//next line will get you the net.netFD
fdmember := val.FieldByName("fd")
//fmt.Println(fdmember)
val1 := reflect.Indirect(fdmember)
//fmt.Println(val1)
netFdPtr := val1.FieldByName("sysfd")
//fmt.Println(netFdPtr)
fd := syscall.Handle(netFdPtr.Uint())
fmt.Println("socket handle: ", fd)Here you're closing socket (I think the main udp socket should NEVER be closed, as it's used for DHT and UTP?) func (s *Socket) destroy() {
delete(sockets, s)
s.destroyed.Set()
// TODO: Perhaps we should only Close the PacketConn if we created it
// ourselves.
// aded code
fmt.Println("socket destroyed")
ptrVal := reflect.ValueOf(s.pc)
//fmt.Println(ptrVal)
//log.Printf("ptrVal: %s", ptrVal)
val := reflect.Indirect(ptrVal)
//fmt.Println(val)
//next line will get you the net.netFD
fdmember := val.FieldByName("fd")
//fmt.Println(fdmember)
val1 := reflect.Indirect(fdmember)
//fmt.Println(val1)
netFdPtr := val1.FieldByName("sysfd")
//fmt.Println(netFdPtr)
fd := syscall.Handle(netFdPtr.Uint())
fmt.Println("socket handle: ", fd)This is the output: As we can see the socket handle (192) is the same. That socket should never be destroyed in func (s *Socket) destroy(). |
|
I've added panic to func (s *Socket) destroy() to trace where it's coming from. This is the result: So we can see destroy() is called from func (s *Socket) reader() func (s *Socket) reader() {
mu.Lock()
defer mu.Unlock()
defer s.destroy()
....So the socket gets destroyed after each read? Of course, if it's a listening udp socket, and it's closed, all subsequent Accept() calls on that socket will fail. I don't understand why the socket is destroyed after each read here and why it works on Linux. If I comment defer s.destroy() there's no more error shown and I can see UDP connections active for the torrent process. |
|
The error you've shown is it. The cause appears to be ReadFrom errors that occur only on Windows, that aren't actually fatal. However any error returned from ReadFrom is currently treated as fatal in Socket.reader. Note that you've misinterpreted how Socket.reader works, it doesn't destroy after every read. Socket.destroy is called if Socket.reader returns, as it's assumed something unrecoverable has occurred. You're correct that this also destroyed the UDP connection used by DHT. The PacketConn should not be closed if the connection was not created inside uTP, but this is not the real issue. The real issue is that we must filter out errors from ReadFrom which do not indicate the connection is no longer usable. Since the only reason the socket would be closed is due to the caller that provided the original PacketConn closing it, my interim solution will be to ignore (or log) errors from ReadFrom in Socket.reader, unless Socket.Close has been explicitly called, in which case Socket.reader will return on error. Secondarily, the PacketConn will only be closed if it was created from within the utp packet, and not provided by an external source (as occurs when called from the torrent packet in NewClient). I'll issue a patch shortly. If you can try it out, it will be appreciated. I'm also trying to test on wine, as I have no Windows available to me. |
|
Thanks for clarifying, now I get it. I tried to change the return from Socket.reader to continue, and there's no more this error. I will test your patch when it's done as well. |
|
I've pushed the change to the utp package. It's a quick fix but I believe it'll solve it for now. |
|
Just an FYI, I'm getting a very similar error very randomly during my testing when adding torrents via magnet link. Here is the output: |
|
Do you want to try with the panic commented out, or changed to a |
|
`read udp [::]:50007: wsarecvfrom: The connection has been broken due to keep-alive activity detecting a failure while the operation was in progress. goroutine 6 [running]: Process finished with exit code 2` |
|
Sorry, and add a |
|
It's awful that this is happening, but I'm not exposed to Windows systems so I can't guess what the correct solution is. |
|
I guess you could rely on WSA* Winsock functions at least in the UDP library, instead of using standard Go's runtime ones. |
|
With the continue it does keep working, this is the output, the "ping"s are from my websocket code pinging from the frontend to the backend... |
Seems like this error is a known bug from anacrolyx torrent anacrolix/torrent#83 To prevent it, I'm creating a single client and modifying the socket.go to make it not raise a panic but a simple error log.
* [WIP] Torrent Generation on not found error As asked in #1517, it allows on-the-fly torrent generation. Since it uses magnet links, it needs some time to connect to peers. So it can't be instant generation, we need the user to wait and try after a minute at least. * Replace Fatal by simple error * attempt at fixing travis * del * Add Anacrolyx dependency * Add back difflib * Remove .torrent suffix in the url example * Add some explanations when file missing page shown * Ignore downloads directory * Either use cache (third-party site) or own download directory * Wrong import * If there is an error then it means we aren't generating a torrent file May it be "torrent not found" or "We do not store torrent files" which are the two only existing errors for this page * hash is never empty * TorrentLink may be empty at times So we add a /download/:hash link if it is * Update README.md * Made a mistake here, need to check if false * Update en-us.all.json * Update CHANGELOG.md * Torrent file generation can be triggered by click on button if JS enabled * Update download.go * Update download.go * Use c.JSON instead of text/template * Return to default behavior if we don't generate the file * Don't do the query if returned to default behavior * Add "Could not generate torrent file" error * Fix JS condition & lower delay until button updates * Start download automatically once torrent file is generated * Fix torrentFileExists() constantly returning false if external torrent download URL * torrent-view-data is two tables instead of one This allows the removal of useless things without any problem (e.g Website link), but also a better responsibe design since the previous one separated stats after a certain res looking very wonky * CSS changes to go along * Remove useless <b></b> * Update main.css * In torrentFileExists, check if filestorage path exists instead of looking at the domain in torrent link When checking if the file is stored on another server i used to simply check if the domain name was inside the torrent link, but we can straight up check for filestorage length * Fix JS of on-demand stat fetching * ScrapeAge variable accessible through view.jet.html Contains last scraped time in hours, is at -1 is torrent has never been scraped Stats will get updated if it's either at -1 or above 1460 (2 months old) * Refresh stats if older than two months OR unknown and older than 24h Show last scraped date even if stats are unknown * Add StatsObsolete variable to torrent Indicating if: - They can be shown - They need to be updated * Update scraped data even if Unknown, prevent users from trying to fetch stats every seconds * Torrent file stored locally by default * no need to do all of that if no filestorage * fix filestorage path * Fix torrent download button stuck on "Generating torrent file" at rare times * fix some css rules that didn't work on IE * Fix panic error Seems like this error is a known bug from anacrolyx torrent anacrolix/torrent#83 To prevent it, I'm creating a single client and modifying the socket.go to make it not raise a panic but a simple error log.
* [WIP] Torrent Generation on not found error As asked in #1517, it allows on-the-fly torrent generation. Since it uses magnet links, it needs some time to connect to peers. So it can't be instant generation, we need the user to wait and try after a minute at least. * Replace Fatal by simple error * attempt at fixing travis * del * Add Anacrolyx dependency * Add back difflib * Remove .torrent suffix in the url example * Add some explanations when file missing page shown * Ignore downloads directory * Either use cache (third-party site) or own download directory * Wrong import * If there is an error then it means we aren't generating a torrent file May it be "torrent not found" or "We do not store torrent files" which are the two only existing errors for this page * hash is never empty * TorrentLink may be empty at times So we add a /download/:hash link if it is * Update README.md * Made a mistake here, need to check if false * Update en-us.all.json * Update CHANGELOG.md * Torrent file generation can be triggered by click on button if JS enabled * Update download.go * Update download.go * Use c.JSON instead of text/template * Return to default behavior if we don't generate the file * Don't do the query if returned to default behavior * Add "Could not generate torrent file" error * Fix JS condition & lower delay until button updates * Start download automatically once torrent file is generated * Fix torrentFileExists() constantly returning false if external torrent download URL * torrent-view-data is two tables instead of one This allows the removal of useless things without any problem (e.g Website link), but also a better responsibe design since the previous one separated stats after a certain res looking very wonky * CSS changes to go along * Remove useless <b></b> * Update main.css * In torrentFileExists, check if filestorage path exists instead of looking at the domain in torrent link When checking if the file is stored on another server i used to simply check if the domain name was inside the torrent link, but we can straight up check for filestorage length * Fix JS of on-demand stat fetching * ScrapeAge variable accessible through view.jet.html Contains last scraped time in hours, is at -1 is torrent has never been scraped Stats will get updated if it's either at -1 or above 1460 (2 months old) * Refresh stats if older than two months OR unknown and older than 24h Show last scraped date even if stats are unknown * Add StatsObsolete variable to torrent Indicating if: - They can be shown - They need to be updated * Update scraped data even if Unknown, prevent users from trying to fetch stats every seconds * Torrent file stored locally by default * no need to do all of that if no filestorage * fix filestorage path * Fix torrent download button stuck on "Generating torrent file" at rare times * fix some css rules that didn't work on IE * Fix panic error Seems like this error is a known bug from anacrolyx torrent anacrolix/torrent#83 To prevent it, I'm creating a single client and modifying the socket.go to make it not raise a panic but a simple error log. * Removing some logs
|
ths |
|
que? |
When running on Windows, after 1-2 minute of downloading, I get non stop error messages that keep scrolling infinitely. When I restart torrent, it works ok, but after 1 minute the same happens again.
When I checked the network activity of the torrent process after the error kicks in, I find out that it "loses" all UDP connections and only TCP connections remain active.
This might be an error in UDP socket implementation for Windows in the network libraries you're using. Or something else.
The text was updated successfully, but these errors were encountered: