hitesh@hitesh:$ ctorrent -v piyush.torrent
META INFO
Announce: http://172.24.32.242:6969/announce
Created On: Thu Mar 6 22:07:13 2008
Piece length: 16384
FILES INFO
<1> piyush [142404]
Total: 0 MB
warn, couldn't set bit field refer file "piyush.torrent.bf": No such file or directory
This is normal if you are starting or seeding.
1204839788 DL need: 16K UL need: 0K Cache: 32K Used: 0K
Listening on 0.0.0.0:2706
Press 'h' or '?' for help (display/control client options).
- 0/0/1 [0/9/0] 0MB,0MB | 0,0K/s | 0,0K E:0,0 Connecting
1204839788 Cache: 0K/1M Hits: 0 Miss: 0 0% Pre: 0/0
1204839788 Connected to tracker
1204839788 Disconnected from tracker
1204839788 Tracker did not supply peers count.
1204839788 new peers=1; next check in 1800 sec
1204839788 Connection from 172.24.32.242:33680 (peer 0x807d578)
1204839788 0x807d578: remote closed
1204839788 close: bad handshake
1204839788 0x807d578 closed
\ 0/0/2 [0/9/0] 0MB,0MB | 0,0K/s | 0,0K E:0,1
1204839789 Cache: 0K/1M Hits: 0 Miss: 0 0% Pre: 0/0
| 0/0/2 [0/9/0] 0MB,0MB | 0,0K/s | 0,0K E:0,1
1204839790 Cache: 0K/1M Hits: 0 Miss: 0 0% Pre: 0/0
---
---
---
---
And it keeps on trying for indefinite time (sometimes start immediately).
Every time when it tries to handshake with the seeder, it fails.
Tracker: bttrack (tracker version: 3.4.2)
Seeder: Enhanced CTorrent dnh3.2
Leecher (my client) : Enhanced CTorrent dnh3.2
Logged In: YES
user_id=1313842
Originator: NO
If the seeder and leecher are running on the same machine, or appear to each other to have the same IP address, then this is by design. The client has checks to detect and reject connections to or from itself. This should be explicitly reported with dnh3.2, unless I missed a case.
Logged In: YES
user_id=2029562
Originator: YES
Yes you are right that if seeder and leecher are running on the same machine then it must reject the connection. But in my case tracker and seeder are on one machine(172.24.32.242) and leecher is on other machine(172.24.32.237). I didn't checked with the other versions of the Ctorrent. Is it a problem if we have seeder, leecher and tracker as mentioned above? I will try with each one of them running on different machines.
Logged In: YES
user_id=1313842
Originator: NO
Been thinking about this today and ran a test, but was unable to duplicate the problem even with dnh3.2.
There was a related change in dnh3.3 (support for sending the "ip" parameter to the tracker), but judging from the log above I don't think it's relevant in this case.
If this is still a problem, I'd like to see the results using the latest version, including verbose logs from both the seeder and the leecher. The leecher's log above appears to show that the seeder closed the connection, so hopefully that would reveal more information. If not I could add something to dump additional data during the handshake phase in order to further diagnose it.