2 small issues with the client I see

[CraigglesO]

So when I was experimenting with your software and may others to see how they interacted with my tracker, I noticed 2 things:

1. When you start up a seeded file it sends an announce with START->ANNOUNCE(EVENT:1)->ANNOUNCE(EVENT:2) with the event of 2 (completed) every time you start up a full downloaded file. I don't believe this is right because sending a LEFT = 0 bytes than sending a start to the tracker is enough to tell the tracker you are a seeder. And since we use magnet files now, to start with no file knowledge I just send an unsigned (-1) for LEFT if I don't have the metadata yet. Basically openTracker and others on event 2 increment there "downloaded" count every time, so this pollutes that number.

2. When you delete the torrent, it does not signal a STOP (EVENT 3). I am suspecting it does this when you quit the app though?

[feross]

@CraigglesO Just to confirm: what program did you use to find these results? WebTorrent Desktop? The webtorrent npm package? Or the bittorrent-tracker package directly?

[feross]

Related issue: webtorrent/webtorrent#991

[CraigglesO]

The webtorrent desktop app. I should have checked the webtorrent issues first. Sorry.

edit - the checkbox pause start is what I am talking about for 1 and for 2 when I right click delete.

[feross]

@CraigglesO The first issue should be fix in webtorrent library now, but we haven't done a WebTorrent Desktop release yet so you'll have to wait for one before the fix gets in.

[feross]

When you delete the torrent, it does not signal a STOP (EVENT 3). I am suspecting it does this when you quit the app though?

Why is this important? I think we are calling stop() but we're destroying the connection too, so it doesn't get sent. Are you testing with http, udp, or ws?

[CraigglesO]

UDP - every other torrent app I have played with sends a stop on shutdown, and it is super convenient for my tracker because it removes the host from the list.

Obviously with UDP their is no 'connection' as it just sends and hopes the message makes it otherwise it tries again after a certain period of time. But ws stays connected so I see why you don't send STOP for ws.

Out of curiosity, do you follow the exact same protocol as http as you do with ws? Just sending JSON bencodes? I'm still implementing udp and working my way up.

[feross]

@CraigglesO UDP - every other torrent app I have played with sends a stop on shutdown, and it is super convenient for my tracker because it removes the host from the list.

Yeah, that's fair. We are trying to call stop, but it's not guaranteed to get sent before we force the udp socket closed. You can see that here: https://github.com/feross/torrent-discovery/blob/db3a8dc76a01cb5bfaf581b73e7d9562e987ec3d/index.js#L99-L100

To be fair, your tracker needs to prune peers after a certain amount of time anyway, otherwise you'll slowly accumulate dead peers from clients that never send STOP (which can happen if their computer loses power, or if they don't send it reliably like webtorrent right now).

There's no way for us to really know that our STOP message was received, so maybe the best we can do is to just wait a tick before calling destroy()?

@CraigglesO Out of curiosity, do you follow the exact same protocol as http as you do with ws? Just sending JSON bencodes?

Yeah, it's the same protocol, but as JSON. There's an extra message for forwarding signaling data (which is necessary for doing webrtc connections)

[feross]

@CraigglesO - just sent a PR to torrent-discovery that attempts to next tick the tracker.destroy() call so that tracker.stop() has time to actually send the packet.

webtorrent/torrent-discovery#31

@CraigglesO - Can you test it and see if it resolves your issue? If you don't want to figure out the git commands to pull down the PR, you can quick-and-dirty test it by going into your node_modules/torrent-discovery folder and making the same code change.