Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

white/blacklist implemented (#44) + docs/tests updated #57

Merged
merged 1 commit into from
Jan 29, 2015
Merged

white/blacklist implemented (#44) + docs/tests updated #57

merged 1 commit into from
Jan 29, 2015

Conversation

sidd
Copy link
Contributor

@sidd sidd commented Jan 29, 2015

I've added a simple filter option to the server creation parameters as per issue #44.

If filter() returns false, a warning is emitted and the infoHash is not added to self._torrents. The test checks this by ensuring that the infoHash does not appear in a scrape request.

test('http nonwhitelisted torrent does not appear in scrape', function (t) {
var server = new Server({
filter: function (hash) {
return hash !== parsedBitlove
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hash is a string and parsedBitlove is an object, so this will never be true

@feross
Copy link
Member

feross commented Jan 29, 2015

Good PR, but the tests need a bit of work. Don't worry about it though - I can fix them up :)

@feross feross merged commit 5507979 into webtorrent:master Jan 29, 2015
@feross
Copy link
Member

feross commented Jan 29, 2015

Thanks, this is released (with some other breaking changes) as 3.0.0.

@feross
Copy link
Member

feross commented Jan 30, 2015

@S1DD Btw, if you're interested the other breaking changes in 3.0.0 are in this commit: 82e6792 (The fixed filter test is in there)

Thanks again for sending this in!

@sidd
Copy link
Contributor Author

sidd commented Jan 31, 2015

Yep, took a look at it and things are making a lot more sense now. On a tangential note, I'm trying to figure out the best way to solve the storage adapter issue that was briefly discussed in #44.

@feross
Copy link
Member

feross commented Jan 31, 2015

I believe Astro already solved issue #44 with this PR:
#45 Unless there's some
other functionality that's needed.

On Fri Jan 30 2015 at 4:00:07 PM Sidd Sridharan notifications@github.com
wrote:

Yep, took a look at it and things are making a lot more sense now. On a
tangential note, I'm trying to figure out the best way to solve the storage
adapter issue that was briefly discussed in #44
#44.


Reply to this email directly or view it on GitHub
#57 (comment)
.

@sidd
Copy link
Contributor Author

sidd commented Jan 31, 2015

Ok, I think I'm just misunderstanding some things then. I'll spend some more time tinkering, thanks!

@feross
Copy link
Member

feross commented Jan 31, 2015

Cool, feel free to ask questions if anything's confusing. I think @astro intended the getSwarm method to be overridable by the user, and that's where you'd interface with a custom storage engine.

@sidd
Copy link
Contributor Author

sidd commented Jan 31, 2015

Alright, I'm unable to see how to override getSwarm and only getSwarm to check if the infohash exists in the database, since in _onAnnounce, we're not using a callback in order to wait until the DB query finishes. I feel like I'm just missing something completely!

@feross
Copy link
Member

feross commented Jan 31, 2015

Pasting from IRC for posterity:

sidd: sup
00:41 <•feross> so, the way to override getSwarm is literally just overwrite it on the tracker server instance
00:41 <•feross> like this:
00:41 <•feross> var server = new TrackerServer({ udp: true, http: true })
00:41 <•feross> server.getSwarm = MySwarm
00:42 <•feross> and then you define a MySwarm class
00:42 <•feross> It needs to have the same API as https://github.com/feross/bittorrent-tracker/blob/master/lib/swarm.js
00:42 <•feross> which is to say, it needs:
00:42 <•feross> - a constructor
00:42 ahhhh
00:42 <•feross> - an announce method
00:42 <•feross> - a scrape method
00:42 thank you
00:43 <•feross> you don't need to implement the methods that start with _, since they're private
00:43 <•feross> but basically, you handle when swarm.announce gets called by storing into a database or whatever backend you want
00:44 <•feross> the implementation in lib/swarm.js just stores everything in a javascript object in memory

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants