Skip to content

fixing error in closing peer#116

Open
liangmingyuanneo wants to merge 4 commits intojackpal:masterfrom
liangmingyuanneo:master
Open

fixing error in closing peer#116
liangmingyuanneo wants to merge 4 commits intojackpal:masterfrom
liangmingyuanneo:master

Conversation

@liangmingyuanneo
Copy link
Contributor

Taipei-Torrent should close peer when err != io.EOF, otherwise, as in the original codes, it will close peer when err ==io.EOF. But this will happen every time when it can not receive a piece by function "err = ts.RequestBlock2(p, k, false)". Because this function will return io.EOF when its peers do not have the pieces it needs. After closing, it can not download pieces from the peer because there is no connection between them anymore, even though the peer have the pieces it need again. I have tested this for one day to find the reasons that Taipei-Torrent can not receive pieces after it do not get piece one time and set to "UNINTERESTED" to the peer.

Taipei-Torrent should close peer when err != io.EOF, otherwise, as in the original codes, it will close peer when err ==io.EOF. But this will happen every time when it can not receive a piece by  function "err = ts.RequestBlock2(p, k, false)". Because this function will return io.EOF when its peers do not have the pieces it needs. After closing, it can not download pieces from the peer because there is no connection between them anymore.
In original codes, Taipei-Torrent could not download pieces from the peer which have been set to "UNINTERESTED" by it again, because it download piece continue after it has got a "PIECE". When it set "UNINTERESTED" to its peer, it stops to download. So we should boot it again after the peer have pieces it needs again.
I have found a problem that when two leechers download from one seeder at the same time, they do not share pieces themselves and just receive pieces from the seeder. I did experiments all the afternoon and found that the two leecher always generate the same random piece number when downloading from seeder. So they can not have different pieces to exchange.
In original codes, Taipei-Torrent could not download pieces from the peer which have been set to "UNINTERESTED" by it again, because it download piece continue after it has got a "PIECE". When it set "UNINTERESTED" to its peer, it stops to download. So we should boot it again after the peer have pieces it needs again.
@luisdavim
Copy link

won't this cause the connection to remain open when you hit the actual end of the file?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Comments