Opened 11 years ago

Closed 11 years ago

Last modified 4 years ago

#2753 closed Enhancement (wontfix)

Manual add peer

Reported by: Elbandi Owned by: charles
Priority: Normal Milestone: None Set
Component: libtransmission Version: 1.76
Severity: Normal Keywords:
Cc: amontero@…

Description

Manual add a peer to peerlist. (situation: my mate want to send something to me, he created a trackerless torrent from that, send me his peer address, so i can download from him)

Attachments (1)

manual_add_peer.patch (2.7 KB) - added by Elbandi 11 years ago.

Download all attachments as: .zip

Change History (11)

Changed 11 years ago by Elbandi

comment:1 Changed 11 years ago by Waldorf

I'm sure this idea has potential and it's interesting nonetheless. However, in your case, you're better of using a tracker. That's what they are for. Check out an open tracker or Wikipedia.

comment:2 Changed 11 years ago by jch

Ehm... trackerless torrents are supposed to work with the DHT. You should be able to connect to each other, although it might take a few minutes.

--Juliusz

comment:3 Changed 11 years ago by User294

Btw. as for me I'm finding this useful as fallback option.

Right now I just got silly issue (I would file a separate bug about this):
My seedbox can connect my desktop and can communicate if it finds it via trackers.

However, it can't find me over DHT so some trackerless torrents (where my desktop is the only source of file) can't be uploaded to seedbox machine at all. I.e. download never starts and seedbox never downloads copy of file while it supposed me to help transfer file at good speed. Adding peer manually could be a thing which will save a day, even if something goes wrong (sure, DHT should work on it's own, but you see, I have a scenario where this fails for some unknown reasons).

comment:4 follow-up: Changed 11 years ago by jch

You're probably blocking UDP in a firewall somewhere. Don't.

You remind me of the early Internet, where FTP servers were advertised both by their name and by their IP address, in case your site didn't have DNS ;-)

Charles, Livings, I suggest marking this as wontfix.

comment:5 Changed 11 years ago by charles

  • Resolution set to wontfix
  • Status changed from new to closed

In general I'm neutral on this, but IMO the current patch is not sufficient -- it doesn't really add the feature; it just adds a fraction of it to scratch a particular itch. If we're going to support peer adding, we also need to put it in the mac client, the gtk client, the web client, and the qt client. Also this patch adds a new rpc call not documented in rpc-spec.txt.

...Transmisson's goal of having multiple native interfaces is a Good Thing in general, but it really forces one to think long and hard about user-visible changes before adding them. I guess since Transmission is the "no bloat" client, maybe even that high bar is a Good Thing too. :/

comment:6 in reply to: ↑ 4 Changed 11 years ago by User294

Replying to jch:

You're probably blocking UDP in a firewall somewhere. Don't.

I do not block UDP, ever. Furthermore, DHT is up on both sides and does not considers itself as firewalled ("good, 100+ nodes"). Furthermore at least some nodes can communicate with both sides and if it happens there are other peers downloading file, transfer could happen and some peers on both sides found by DHT, some peers are inbound ones due to DHT, etc. So it's weird things are not working as expected.

Have you ever tried the following "corner" testcase: Start 2 transmissions, create tracker-less torrent and try to get file from one Transmission client to another Transmission client through magnetized transfer. Roughly resembles what I'm doing at the moment. Looks like I would need to do a very verbose debug of DHT operations and TCP connectivity to understand what's going. How can I enable packet-level debug to file or so? Same goes for TCP connections establishment as well.

My idea currently is:
1) I will install Transmission 1.80 on both sides (one runs b5 and one runs a bit different SVN revision close to b5 as well).
2) I would create a special test data file noone haves yet and trackerless torrent with unique infohash nobody haves at the moment for sure so no other peers would interfere with my test.
3) I would try to transfer file from one client to another by finding 1st client via DHT
4) If that's not works I would need to do an advanced network debugging:
4.1) I would have to see how 1st client publishes things to DHT and published information is valid.
4.2) I would have to see if other client can locate 1st one via DHT and if DHT returns proper results.
4.3) Then I have to see if TCP connections attempted, if it uses proper IP and port and what happens, etc.

All this tricky and would require certain time and I may need your help. At least can you tell me how do I enable logging all network-related operations on packet level to a file or so? Using sniffer proven to be not an good idea due to traffic encryption. I bet you debugged TCP connectivity and DHT operations at early phases of development anyhow? Looks like I need to do something like this.

P.S. I have idea what the Kademlia is, why TCP and UDP are used both, why "peer" is not the same as "node", what "firewalled" means for DHT, etc. That's why I'm finding inability to transfer file strange and want to extensively debug it.

comment:8 Changed 7 years ago by lagrave

I think this should be reconsidered. I currently run Transmission on two machines, A and B. A is at my home network where I have full control over firewalls, portforwarding etc. There the firewall is open and ports are forwarded (all confirmed by th green indicator in the preferences). B however is on a shaky hotel WiFi? that is both slow and with NAT-pmp/Up'n'p disabled. Still, when I download the same torrent on both machines (the purpose is to download it fast to A and then make sure it is seeded from A to B in case B loses connection to the few other seeders of this specific torrent) B finds more seeders than A!? In fact, only B is connected to the only seeder with 100%. Hence the stream actually goes in the "wrong" direction, from B (with non-open 512 kBi connection) to A (with an open 100 Mbi connection).

I want to add this 100% peer to A manually!

comment:9 Changed 5 years ago by sahnovsky

please reopen ticket! It is will be great feature! Maybe 6 ears ago it was strange, but in 2015th it realy needed.

comment:10 Changed 4 years ago by amontero

  • Cc amontero@… added

+1. Subscribing.

Note: See TracTickets for help on using tickets.