LSD Tracker Not Working LSD = 0

[snakyjake]

I have two machines on my local network running QBT, with the same torrent. 
Local Peer Discovery is enabled on both machines.
The LSD tracker = 0 on both machines.  I did see for a short moment LSD tracker = 1, then went to 0.
In the log, both have a line that reads:  Peer ID: -qB31C0-
Any ideas why?

[snakyjake]

I have Global Rate Limits set real low.  But I have "ignore transfer limits on local network" selected.

[ciaobaby]

Any ideas why?:

Peer ID: -qB31C0- means you are running client ver 3.1.12

LSD works a bit like DHT (basically) does and if 'the other client' doesn't respond to the broadcast for whatever reason (no free connections or upload slots etc. etc.) it won't be counted.

Are both machines seeding, downloading or some combination of the two?

[snakyjake]

Both machines were downloading/uploading/combination.
Only one torrent was active on each machine.
I had bandwidth limits for both upload/download, and presume this only affects remote connections, not local LAN.
The LAN machines were not found in the Peer list.
Manually adding the machines to the Peer list did nothing, and have no idea why, and no log.

The LSD tracker eventually found my local peer, but it wasn't consistent and took forever.  It seemed to work just like DHT like you said; but I'm expecting LSD to have priority and no limits.
Would be nice to turn off remote connections temporary, and just allow LAN data exchange.

[ciaobaby]

As both machines are 'competing' for the same pieces  why would you expect them to be communicating?
Most likely they BOTH will have the same pieces, so neither one is of any use to the other. A peer has to be 'interesting to' or 'interested in' the other to even make an optimistic' connection.
Two peers downloading one payload is a truly pointless exercise for several reason. one is as above, another is that some clients have an implied "do not allow same IP connections"  for a single torrent.


From the libtorrent manual

For seeds that are critical for a delivery system, you most likely want to allow multiple connections from the same IP. That way two people from behind the same NAT can use the service simultaneously. This is controlled by session_settings::allow_multiple_connections_per_ip.

Even though uTorrent does not use libtorrent, as far as I am aware that is the only client that exposes the "Allow same IP" in the user settings. So if you think that two machines on one router is going to download faster, you are mistaken.

Best practice for seeding from two clients is to run one client to 75% - 80% complete before you start the task on the second one, then both can assist the swarm without starving each other.

[snakyjake]

Machine A has nearly completed files A, B, C, D.
Machine B has completed files E, F, G, H.
I made it so Machine B is interested in files A, B, C, D; Machine A has no other file interests.

[ciaobaby]

Okay, keep going, need more information before the next set of guessing as to why it might be occurring and whether it is a possible libtorrent bug, or merely a 'use case' problem.

to get you started;

Download state (%) and status?
Port numbers?
peer flags (if you happen to spot them)
Check the "Blocked IPs" log for the private IPs
Anything untoward appearing in the execution log?
Can you 'ping' each machine from the other (I'm guessing yes if they occasionally 'see' each other
Wired or wireless?
Have you disconnected the Internet connection? (leave them on the network though)
Try enabling the in-client tracker with the Internet off.  this probably will not make any difference,  but it is one more thing off the check-list.

[snakyjake]

I think the key has to do with this...

Eventually the two clients would see each other and share (this took many minutes).
Then stop and wait for quite a long time.
The start sharing with each other again, but this time faster.

Here's what the behavior has me guessing:
Peers do not get priority.
Depending on the total peers available and Internet speed, it can take QBT a while to find a local peer.  I'll test this out be disconnecting from the Internet.
Once QBT finds a local peer, and finds the speed to be fast...maybe it then gives the local peer priority.

My expectations:
Local peers should be found immediately and given priority.
The tracker should always list the local peers.
Limits do not apply to local peers (which I believe is implemented for speed, but not sure about connection limits).

Answers...

Download state (%) and status?  Machine A is < 100% complete with files A, B, C, D.  Machine B is 0% completed for files A, B, C, D....but 100% complete for files E, F, G, H.

Port numbers?  Each client randomly sets a port on startup.  Both clients have no problems connecting to the Internet to send/receive traffic.

Can you 'ping' each machine from the other (I'm guessing yes if they occasionally 'see' each other?  Yes.  I connect to the other machine via RDP.

peer flags (if you happen to spot them)?  The peer IP Address is not in the Peer tab.  I also tried to manually enter the IP:Port and the machine didn't appear in the list (of the many other peers).

Check the "Blocked IPs" log for the private IPs?  I'll check.

Anything untoward appearing in the execution log?  Nothing that I notice.

Wired or wireless?  Both.  Machine A is wireless with excellent connection; Machine B is wired.

Have you disconnected the Internet connection? (leave them on the network though)  No.

Try enabling the in-client tracker with the Internet off.  this probably will not make any difference,  but it is one more thing off the check-list.  This was enabled (default).

[ciaobaby]

Local peers should be found immediately and given priority.

They have to connectable first, which appears to not be the case here.

The tracker should always list the local peers.

Nope! A tracker that is outside the local network will not even know those peers exist in the 'local' scope.

quote] Each client randomly sets a port on startup.[/quote] That won't help, especially if they happen to select the same port. What works in the much wider scope of the Internet
probably won't in the local scope.

Machine A is wireless with excellent connection; Machine B is wired.

The signal strength is not important, some ISP provided router/modems are not particularly good with routing local wireless to local ethernet

[Switeck]

[quote="snakyjake"]Eventually the two clients would see each other and share (this took many minutes).
Then stop and wait for quite a long time.
The start sharing with each other again, but this time faster.

Here's what the behavior has me guessing:
Peers do not get priority.
Depending on the total peers available and Internet speed, it can take QBT a while to find a local peer.  I'll test this out be disconnecting from the Internet.
Once QBT finds a local peer, and finds the speed to be fast...maybe it then gives the local peer priority.

My expectations:
Local peers should be found immediately and given priority.
The tracker should always list the local peers.
Limits do not apply to local peers (which I believe is implemented for speed, but not sure about connection limits).[/quote]Local Peers do not get any special treatment it seems for getting connected and staying connected. If anything, even the slightest hiccup in the wireless link (by a running microwave oven nearby?) may be what's causing the starts and stops between the 2 local computers/peers. Either that, or they are running with few upload slots (per torrent or global) and only upload to each other occasionally because of it. Seriously, that's pretty bad behavior since local bandwidth is not nearly as limited as rest-of-internet bandwidth.

On the subject of max connections per torrent and global, local peers probably count against both the global limit and the per torrent limit. So if one of your local peers fills up on OTHER peer/seed connections first -- hitting max connections per torrent or globally, it will neither connect outgoing to the other one NOR allow the other one to connect incoming to it. This despite some/many of the peers/seeds it is connected with being completely idle and effectively useless.

[ciaobaby]

The tracker should always list the local peers.

Only  if there IS a tracker running on the same CIDR range and subnet mask.
and there are other 'issues' that can affect the operation

LPD/LSD (Local Peer Discovery / Local Service Discovery) needs your network to handle IP multicasting, this can be a problem with some lower end routers.

libtorrent has a default [url=http://"https://wiki.theory.org/BitTorrentSpecification#Choking_and_Optimistic_Unchoking"]peer choking algorithm[/url] that behaves like a "round robin" piece downloading strategy where a minimum of three active peers (1 seed, 2 peers) required for a swarm to develop.

[snakyjake]

Still trying to work out this issue.
Here's my current scenario:

In my LAN I'm using Linux+QBT and have downloaded 100% of the torrent payload to the server within my LAN.
I have another machine (laptop) that I want to have a copy of the torrent payload.
I connect the laptop to the LAN (via SOCKS5 for a security reason).
I expect the torrent tracker to use the "Local Service Discovery" and both machines will find each other.
I have enabled embedded tracker on both machines.
But the local machines/peers still don't see each other (not listed in the peers tab).  I have no problems seeing WAN machines.

[ciaobaby]

with this > I connect the laptop to the LAN (via SOCKS5 for a security reason).

Thus making sure that it CANNOT connect to any local machine.


Why not just copy the files across the network? http://windows.microsoft.com/en-gb/wind ... =windows-7

[snakyjake]

They don't have a problem connecting via SOCKS5.  I also use the proxy for peer connections. 

I manually added the embedded tracker with a local IP:9000, and the embedded tracker shows peers.  Sometimes the local seeder shows up in the peers list, and then disappears for a while.  Not sure if it the local seeder is showing up because of the LSD, embedded tracker, or when I manually add a peer. 

The behavior is what I see on another LAN, without SOCKS.

[ciaobaby]

I don't understand why you have a proxy server for "security" reasons when connecting to a LAN machine, it defeats entirely the idea of a "local peer", it means the data has to do a round trip to the Internet when the machines are probably less that ten feet part.