I've noticed TT only connects to peers found using the DHT if we already have the torrent file. But what if we don't have the torrent file and only the infohash?

eg of the restriction: https://github.com/jackpal/Taipei-Torrent/blob/master/torrent/torrent.go#L520

Even if I remove all such restrictions like this (I think there are 2 more of them), I still can't download using just an infohash, for example "magnet:?xt=urn:btih:deca7a89a1dbdc4b213de1c0d5351e92582f31fb", even though I can connect to peers found over the dht for it (and there are several).

What's the deal?

As should be defined in BEP-0014 (still TBD)

Basically, for each torrent we are in, a HTTP-like message is sent to 239.192.152.143:6771. This message is an announcement that we are in the swarm.

When a Taipei-Torrent peer receives such a message, it will automatically connect unless it's already connected.

Tested successfully with aria2c and transmission.

Repro: Uncomment the commented-out-tests in tracker_test.go

Might be some sort of OS-level resource starvation or race condition. Tested on OSX. Fails reproducibly. (Which tends to indicate that it's not a race condition.)

This makes the output more useful (particularly because I'm interested in making TT faster). Here's an example output line:

2015/04/21 22:35:36 [ dsl-4.4.10.iso ] Peers: 9 downloaded: 19349504 (624.00 kB/s) uploaded: 0 ratio: 0.000000 pieces: 35/100

t.M needs to be populated before we can refer to it.

2014/05/04 21:20:03 Starting. 2014/05/04 21:20:03 Listening for peers on port: 7777 panic: runtime error: invalid memory address or nil pointer dereference [signal 0xb code=0x1 addr=0x18 pc=0x3fa6f]

goroutine 16 [running]: runtime.panic(0x335860, 0x551524) /usr/local/go/src/pkg/runtime/panic.c:279 +0xf5 github.com/jackpal/Taipei-Torrent/torrent.NewTorrentSession(0x7fff5fbffb5f, 0x14f, 0x1e61, 0x0, 0x0, 0x0) /Users/yves/go/src/github.com/jackpal/Taipei-Torrent/torrent/torrent.go:169 +0x14f main.main() /Users/yves/go/src/github.com/jackpal/Taipei-Torrent/main.go:62 +0x523

I can't make the bencode code unmarshal strings like:

d1:ad2:id20:abcdefghij0123456789e1:q4:ping1:t2:aa1:y1:qe

I tried this for hours already, thinking I was doing something wrong, but couldn't find a solution. I'm thinking this might be a bug, but I'm not sure. I would appreciate any help.

Unit test to reproduce it:

$ git diff --cached bencode_test.go 
diff --git a/bencode/bencode_test.go b/bencode/bencode_test.go
index cb683af..b48fc79 100644
--- a/bencode/bencode_test.go
+++ b/bencode/bencode_test.go
@@ -3,7 +3,7 @@ package bencode
 import (
        "bytes"
        "fmt"
-//     "jackpal/bencode"
+       //      "jackpal/bencode"
        "os"
        "reflect"
        "testing"
@@ -206,6 +206,15 @@ type SVPair struct {
        v any
 }
 
+var x = map[string]string{"id": "abcdefghij0123456789"}
+var y = map[string]any{
+       "t": "aa",
+       "y": "q",
+       "q": "ping",
+       "a": x,
+}
+
func TestDecode(t *testing.T) {
        tests := []SVPair{
                SVPair{"i0e", int64(0)},
@@ -221,6 +230,7 @@ func TestDecode(t *testing.T) {
                SVPair{"li42e3:abce", []any{42, "abc"}},
                SVPair{"de", map[string]any{}},
                SVPair{"d3:cati1e3:dogi2ee", map[string]any{"cat": 1, "dog": 2}},
+               SVPair{"d1:ad2:id20:abcdefghij0123456789e1:q4:ping1:t2:aa1:y1:qe", y},
        }
        for _, sv := range tests {
                if err := check(sv.s, sv.v); err != nil {
@@ -250,6 +260,7 @@ func TestUnmarshal(t *testing.T) {
                SVPair{"de", map[string]any{}},
                SVPair{"d3:cati1e3:dogi2ee", map[string]any{"cat": 1, "dog": 2}},
                SVPair{"d1:ai10e1:b3:fooe", structA{10, "foo"}},
+               SVPair{"d1:ad2:id20:abcdefghij0123456789e1:q4:ping1:t2:aa1:y1:qe", y},
        }
        for _, sv := range tests {
                if err := checkUnmarshal(sv.s, sv.v); err != nil {

See the discussion in #63. The metadata downloader triggers a load() and a checkPieces() call that gets stuck for a while. This makes the deadlock detector unhappy.

I don't know how to fix this without doing some surgery on the detector.

Should we maybe make the deadlock detector print a stackdump without throwing a panic?

This is the first step towards making Taipei-Torrent available as a library. I've moved all of the files (besides main.go) into the taipei subdirectory, and changedthem to use the taipei package.

There are a lot of changes in the PR, because it's necessary to capitalize the names of all fields used in main.go, since none of them were exported. Later, we can decide what fields really should be exported.

By default, a new peer has no pieces, so it doesn't send a BITFIELD. Only when it has some (or all) pieces does it send a BITFIELD. In the current implementation we only build peerstates' have when receiving BITFIELD. This fix makes sure there is always a have by default.

Fair warning; this is just a proof of concept I'd been thinking about for a bit, and then decided to try when I discovered gowut (Go Web UI Toolkit) earlier this afternoon.

Basically, I've added a struct/API (TorrentControl) for the use of "Torrent Managers" that might be embedded into Taipei-Torrent. Examples of possible managers include a native gui, a webgui, a seedbox remote-control, etc. For now, TorrentControl is almost completely unimplemented, but as an example I've included a toy webgui (super-simple, extremely ugly) that uses it to list the currently running torrents and their percentage of completion (updated every 1 second).

Obviously this is nowhere near ready to merge, but I thought I'd bring it up to get some feedback/suggestions on the idea, and just in case there's a huge fatal flaw in the design that I'm not seeing.

Best Regards.

This PR changes the UPnP code so it doesn't try to exactly match the URN used by a router, as there can be slight differences. Also, it renames getStatusInfo to getExternalIPAddress, and makes it correctly get the external IP address from the router.

The commit is pretty big, so I can split it up if you want.

Every exported function in a program should have a doc comment. The first sentence should be a summary that starts with the name being declared. From effective go.

PR generated by CodeLingo. Install here to drive Continuous Higher Standards.

I have made 4 pull requests, but I find an error with the first pulling with title"fix error in downloading pieces continue ". And I do not know have to undo the pulling. So I make another pull again.

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.

When I use Taipei-Torrent to download file, I have 1 seeder and 10 leechers. I usually meet the problem "Closing peer that sent a bad piece 9 -tt15217_12515306877 reference sha1: [217 254 129 37 191 21 13 134 0 108 169 60 11 41 131 173 232 147 204 164] != piece sha1: [179 220 206 190 193 88 161 163 18 120 145 202 124 252 13 151 217 222 148 52]". What is the reason?