Code Monkey home page Code Monkey logo

bittorrent-protocol's Introduction

bittorrent-protocol travis npm downloads javascript style guide

Simple, robust, BitTorrent wire protocol implementation

Node.js implementation of the BitTorrent peer wire protocol. The protocol is the main communication layer for BitTorrent file transfer.

Also works in the browser with browserify! This module is used by WebTorrent.

install

npm install bittorrent-protocol

usage

The protocol is implemented as a duplex stream, so all you have to do is pipe to and from it.

duplex streams a.pipe(b).pipe(a)
duplex streams a.pipe(b).pipe(a)

(Images from the "harnessing streams" talk by substack.)

import Protocol from 'bittorrent-protocol'
import net from 'net'

net.createServer(socket => {
	const wire = new Protocol()

	// pipe to and from the protocol
	socket.pipe(wire).pipe(socket)

	wire.on('handshake', (infoHash, peerId) => {
    // receive a handshake (infoHash and peerId are hex strings)

		// lets emit a handshake of our own as well
		wire.handshake('my info hash (hex)', 'my peer id (hex)')
	})

	wire.on('unchoke', () => {
		console.log('peer is no longer choking us: ' + wire.peerChoking)
	})
}).listen(6881)

methods

handshaking

Send and receive a handshake from the peer. This is the first message.

// send a handshake to the peer
wire.handshake(infoHash, peerId, { dht: true })
wire.on('handshake', (infoHash, peerId, extensions) => {
	// receive a handshake (infoHash and peerId are hex strings)
  console.log(extensions.dht) // supports DHT (BEP-0005)
  console.log(extensions.extended) // supports extension protocol (BEP-0010)
})

For wire.handshake(), the infoHash and the peerId should be 20 bytes (hex-encoded string or Buffer).

choking

Check if you or the peer is choking.

wire.peerChoking // is the peer choking us?
wire.amChoking // are we choking the peer?

wire.on('choke', () => {
	// the peer is now choking us
})
wire.on('unchoke', () => {
	// peer is no longer choking us
})

interested

See if you or the peer is interested.

wire.peerInterested // is the peer interested in us?
wire.amInterested // are we interested in the peer?

wire.on('interested', () => {
	// peer is now interested
})
wire.on('uninterested', () => {
	// peer is no longer interested
})

bitfield

Exchange piece information with the peer.

// send a bitfield to the peer
wire.bitfield(buffer)
wire.on('bitfield', bitfield => {
	// bitfield received from the peer
})

// send a have message indicating that you have a piece
wire.have(pieceIndex)
wire.on('have', pieceIndex => {
	// peer has sent you a have message
})

You can always see which pieces the peer has

wire.peerPieces.get(i) // returns true if peer has piece i

wire.peerPieces is a BitField, see docs.

requests

Send and respond to requests for pieces.

// request a block from a peer
wire.request(pieceIndex, offset, length, (err, block) => {
	if (err) {
		// there was an error (peer has started choking us etc)
		return
	}
	// got block
})

// cancel a request to a peer
wire.cancel(pieceIndex, offset, length)

// receive a request from a peer
wire.on('request', (pieceIndex, offset, length, callback) => {
	// ... read block ...
	callback(null, block) // respond back to the peer
})

wire.requests     // list of requests we currently have pending {piece, offset, length}
wire.peerRequests // list of requests the peer currently have pending {piece, offset, length}

You can set a request timeout if you want to.

wire.setTimeout(5000) // head request should take a most 5s to finish

If the timeout is triggered the request callback is called with an error and a timeout event is emitted.

dht and port

You can set the extensions flag dht in the handshake to true if you participate in the torrent dht. Afterwards you can send your dht port.

// send your port to the peer
wire.port(dhtPort)
wire.on('port', dhtPort => {
	// peer has sent a port to us
})

You can check to see if the peer supports extensions.

wire.peerExtensions.dht // supports DHT (bep_0005)
wire.peerExtensions.extended // supports extended messages (bep_0005)

keep-alive

You can enable the keep-alive ping (triggered every 60s).

// starts the keep alive
wire.setKeepAlive(true)
wire.on('keep-alive', () => {
	// peer sent a keep alive - just ignore it
})

fast extension (BEP 6)

This module has built-in support for the BitTorrent Fast Extension (BEP 6).

The Fast Extension introduces several messages to make the protocol more efficient: have-none, have-all, suggest, reject, and allowed-fast.

wire.handshake(infoHash, peerId, { fast: true })

wire.hasFast // true if Fast Extension is available, required to call the following methods

wire.haveNone() // instead of wire.bitfield(buffer) with an all-zero buffer
wire.on('have-none', () => {
  // instead of bitfield with an all-zero buffer
})

wire.haveAll() // instead of wire.bitfield(buffer) with an all-one buffer
wire.on('have-all', () => {
  // instead of bitfield with an all-one buffer
})

wire.suggest(pieceIndex) // suggest requesting a piece to the peer
wire.on('suggest', (pieceIndex) => {
  // peer suggests requesting piece
})

wire.on('allowed-fast', (pieceIndex) => {
  // piece may be obtained from peer while choked
})

wire.peerAllowedFastSet // list of allowed-fast pieces

// Note rejection is handled automatically on choke or request error
wire.reject(pieceIndex, offset, length) // reject a request
wire.on('reject', (pieceIndex, offset, length) => {
  // peer rejected a request
})

extension protocol (BEP 10)

This module has built-in support for the BitTorrent Extension Protocol (BEP 10).

The intention of BEP 10 is to provide a simple and thin transport for extensions to the bittorrent protocol. Most extensions to the protocol use BEP 10 so they can add new features to the protocol without interfering with the standard bittorrent protocol or clients that don't support the new extension.

An example of a BitTorrent extension that uses BEP 10 is ut_metadata (BEP 9), the extension that allows magnet uris to work.

wire.extended(code, buffer)

This package, bittorrent-protocol, also provides an extension API to make it easy to add extensions to this module using the "extension protocol" (BEP 10). For example, to support ut_metadata (BEP 9), you need only install the ut_metadata npm module and call wire.use(). See the Extension API section for more information.

transfer stats

Check how many bytes you have uploaded and download, and current speed

wire.uploaded // number of bytes uploaded
wire.downloaded // number of bytes downloaded

wire.uploadSpeed() // upload speed - bytes per second
wire.downloadSpeed() // download speed - bytes per second

wire.on('download', numberOfBytes => {
  ...
})
wire.on('upload', numberOfBytes => {
  ...
})

extension api

This package supports a simple extension API so you can extend the default protocol functionality with common protocol extensions like ut_metadata (magnet uris).

Here are the bittorrent-protocol extensions that we know about:

  • ut_metadata - Extension for Peers to Send Metadata Files (BEP 9)
  • ut_pex - Extension for Peer Discovery (PEX)
  • Add yours here! Send a pull request!

In short, an extension can register itself with at a certain name, which will be added to the extended protocol handshake sent to the remote peer. Extensions can also hook events like 'handshake' and 'extended'. To use an extension, simply require it and call wire.use().

Here is an example of the ut_metadata extension being used with bittorrent-protocol:

import Protocol from 'bittorrent-protocol'
import net from 'net'
import ut_metadata from 'ut_metadata'

net.createServer(socket => {
  const wire = new Protocol()
  socket.pipe(wire).pipe(socket)

  // initialize the extension
  wire.use(ut_metadata())

  // all `ut_metadata` functionality can now be accessed at wire.ut_metadata

  // ask the peer to send us metadata
  wire.ut_metadata.fetch()

  // 'metadata' event will fire when the metadata arrives and is verified to be correct!
  wire.ut_metadata.on('metadata', metadata => {
    // got metadata!

    // Note: the event will not fire if the peer does not support ut_metadata, if they
    // don't have metadata yet either, if they repeatedly send invalid data, or if they
    // simply don't respond.
  })

  // optionally, listen to the 'warning' event if you want to know that metadata is
  // probably not going to arrive for one of the above reasons.
  wire.ut_metadata.on('warning', err => {
    console.log(err.message)
  })

  // handle handshake
  wire.on('handshake', (infoHash, peerId) => {
    // receive a handshake (infoHash and peerId are hex strings)
    wire.handshake(new Buffer('my info hash'), new Buffer('my peer id'))
  })

}).listen(6881)

If you want to write your own extension, take a look at the ut_metadata index.js file to see how it's done.

license

MIT. Copyright (c) Feross Aboukhadijeh, Mathias Buus, and WebTorrent, LLC.

bittorrent-protocol's People

Contributors

alxhotel avatar astro avatar danielroe avatar diegorbaquero avatar emschwartz avatar feross avatar greenkeeper[bot] avatar greenkeeperio-bot avatar ivan1986 avatar jhiesey avatar jimmywarting avatar king-11 avatar kirillovarchi avatar paullouisageneau avatar renovate-bot avatar renovate[bot] avatar semantic-release-bot avatar thaunknown avatar transitive-bullshit avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

bittorrent-protocol's Issues

Switch from Tape to Jest

What version of this package are you using? Latest

What problem do you want to solve? Use the market leading unit test framework

What do you think is the correct solution to this problem?? it would be easier to engage others learning through the unit tests

Are you willing to submit a pull request to implement this change? yes

Action required: Greenkeeper could not be activated 🚨

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

Once you have installed CI on this repository, you’ll need to re-trigger Greenkeeper’s initial Pull Request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

An in-range update of standard is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 11.0.1 of standard was just published.

Branch Build failing 🚨
Dependency standard
Current Version 11.0.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

standard is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Commits

The new version differs by 20 commits.

  • 670a3be authors
  • b7e6cbc 11.0.1
  • 34a3c40 Merge pull request #1092 from watson/elastic-logo
  • 5382643 Replace Opbeat with Elastic logo
  • c40c799 Merge pull request #1091 from mackermans/master
  • 504fcff docs(README): update typeform logo
  • a5b779f Swap README.md and RULES.md symlinks (#1090)
  • e818224 Merge pull request #1072 from standard/greenkeeper/eslint-plugin-react-7.7.0
  • 9dc888f Merge branch 'master' into greenkeeper/eslint-plugin-react-7.7.0
  • a5293dd Merge pull request #1075 from standard/greenkeeper/eslint-plugin-import-2.9.0
  • ebf6620 Merge pull request #1087 from standard/greenkeeper/eslint-plugin-promise-3.7.0
  • 116a871 fix(package): update eslint-plugin-promise to version 3.7.0
  • 738edc4 readme: add standard talk
  • c93ac0d Merge pull request #1076 from tumobi/fix-links
  • 4f8c1f5 Fix webstorm.md links

There are 20 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Getting odd error.

Im playing around with the code but keep getting this error when i tell utorrent to connect.

192.168.1.10:2432
  bittorrent-protocol [6b84ad93] new wire +0ms
  bittorrent-protocol [6b84ad93] end +19s
  bittorrent-protocol [6b84ad93] got uninterested +1ms
  bittorrent-protocol [6b84ad93] got choke +1ms
destroy (error: socket close)
  bittorrent-protocol [6b84ad93] destroy +1ms
  bittorrent-protocol [6b84ad93] end +1ms
  bittorrent-protocol [6b84ad93] got uninterested +0ms
  bittorrent-protocol [6b84ad93] got choke +1ms
192.168.1.10:2435
  bittorrent-protocol [570342ee] new wire +41s
  bittorrent-protocol [570342ee] Error: wire not speaking BitTorrent protocol (♥??Q"!U??↨w~▬=0Kr???K??,??w??O#\h??*-??3??
?‼D+►p??-LW??A`?m${?,??I??????a??I
????Z?????\?a??g?B♦q???/??????p??????↑♣???3??E?y??????????G?!J??♥??F?_C??1?w???%??►L?vK???''\7????;?\z?`♂_) +2ms
  bittorrent-protocol [570342ee] end +1ms
  bittorrent-protocol [570342ee] got uninterested +0ms
  bittorrent-protocol [570342ee] got choke +1ms
destroy (error: socket close)
  bittorrent-protocol [570342ee] destroy +5ms
  bittorrent-protocol [570342ee] end +1ms
  bittorrent-protocol [570342ee] got uninterested +0ms
  bittorrent-protocol [570342ee] got choke +1ms

An in-range update of readable-stream is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 2.3.5 of readable-stream was just published.

Branch Build failing 🚨
Dependency readable-stream
Current Version 2.3.4
Type dependency

This version is covered by your current version range and after updating it in your project the build failed.

readable-stream is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details
  • continuous-integration/travis-ci/push The Travis CI build failed Details

Release Notes v2.3.5
Commits

The new version differs by 4 commits ahead by 4, behind by 1.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Handshake/extended API issue

In _onHandshake() we emit the 'handshake' event where we expect the handler to send with handshake() synchronously. If the handler defers handshaking the further body of _onHandshake() will send the extended() message before the actual protocol handshake(), which is a protocol violation.

Is this something you want to get sorted out? A deviation from the current assumptions about callers will probably break API compatibility.

npm install fails

I'm not sure if this is on my end.

npm http GET https://registry.npmjs.org/bittorent-protocol

npm ERR! Error: failed to fetch from registry: bittorent-protocol
npm ERR! at /usr/share/npm/lib/utils/npm-registry-client/get.js:139:12
npm ERR! at cb (/usr/share/npm/lib/utils/npm-registry-client/request.js:31:9)
npm ERR! at Request._callback (/usr/share/npm/lib/utils/npm-registry-client/request.js:136:18)
npm ERR! at Request.callback (/usr/lib/nodejs/request/main.js:119:22)
npm ERR! at Request. (/usr/lib/nodejs/request/main.js:212:58)
npm ERR! at Request.emit (events.js:88:20)
npm ERR! at ClientRequest. (/usr/lib/nodejs/request/main.js:412:12)
npm ERR! at ClientRequest.emit (events.js:67:17)
npm ERR! at HTTPParser.onIncoming (http.js:1261:11)
npm ERR! at HTTPParser.onHeadersComplete (http.js:102:31)
npm ERR! You may report this log at:
npm ERR! http://bugs.debian.org/npm
npm ERR! or use
npm ERR! reportbug --attach /home/valarauca/npm-debug.log npm
npm ERR!
npm ERR! System Linux 3.2.0-60-generic
npm ERR! command "node" "/usr/bin/npm" "install" "bittorent-protocol"
npm ERR! cwd /home/valarauca
npm ERR! node -v v0.6.12
npm ERR! npm -v 1.1.4
npm ERR! message failed to fetch from registry: bittorent-protocol
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR! /home/valarauca/npm-debug.log
npm not ok

Reset unchoked/interested state on 'end'

Just an idea: wire instances have state bits (unchoked/interested) that have an initial default.

I'd hook on('interested') to potentially unchoke a peer, and then on('uninterested') to remove them from the list of unchokable peers. I'd do the latter equivalently on wire disconnect, on('end').

Hence the question: should we emit('uninterested') if the peer state was interested but the wire ended? Same for emit('choked')?

The changes would be minimal but the semantics would make usage easier.

use `buffer-xor/inplace.js` instead of default `buffer-xor`

const xor = require('buffer-xor')

- const xor = require('buffer-xor') 
+ const xor = require('buffer-xor/inplace.js') 

I do not see hash2Buffer being used for something else, so it might be a improvement to just modify the original array.

const hash2Buffer = Buffer.from(sha1.sync(Buffer.from(this._utfToHex('req2') + infoHash, 'hex')), 'hex')
const hash3Buffer = Buffer.from(sha1.sync(Buffer.from(this._utfToHex('req3') + this._sharedSecret, 'hex')), 'hex')
const hashesXorBuffer = xor(hash2Buffer, hash3Buffer)


What i think is better with inplace.js is that it can support plain Uint8Array or any other array for that matter...
& it don't depend on safe-buffer, but still require you to install it...

An in-range update of tape is breaking the build 🚨

Version 4.9.0 of tape was just published.

Branch Build failing 🚨
Dependency tape
Current Version 4.8.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

tape is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push The Travis CI build failed Details

Commits

The new version differs by 27 commits.

  • ea6d91e v4.9.0
  • 6867840 [Deps] update object-inspect, resolve
  • 4919e40 [Tests] on node v9; use nvm install-latest-npm
  • f26375c Merge pull request #420 from inadarei/global-depth-env-var
  • 17276d7 [New] use process.env.NODE_TAPE_OBJECT_PRINT_DEPTH for the default object print depth.
  • 0e870c6 Merge pull request #408 from johnhenry/feature/on-failure
  • 00aa133 Add "onFinish" listener to test harness.
  • 0e68b2d [Dev Deps] update js-yaml
  • 10b7dcd [Fix] fix stack where actual is falsy
  • 13173a5 Merge pull request #402 from nhamer/stack_strip
  • f90e487 normalize path separators in stacks
  • b66f8f8 [Deps] update function-bind
  • cc69501 Merge pull request #387 from fongandrew/master
  • bf5a750 Handle spaces in path name for setting file, line no
  • 3c2087a Test name with spaces

There are 27 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Emit the wire's peerId on close

What version of this package are you using?
3.4.2

What problem do you want to solve?
I'm tracking peers with an extension and would like to more easily remove peers from the list of peers when their wire is closed. The problem is when the wire closes it isn't clear which peerId the close event was for. This makes removing left peers unnecessarily difficult.

What do you think is the correct solution to this problem?
Emit the wire's peerId in the 'close' event when the wire closes.

  destroy () {
    if (this.destroyed) return
    this.destroyed = true
    this._debug('destroy')
    this.emit('close', this.peerId) // <----- Emit the wire's peerId
    this.end()
  }

Are you willing to submit a pull request to implement this change?
Yes

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Detected dependencies

github-actions
.github/workflows/ci.yml
  • actions/checkout v3
  • actions/setup-node v3
.github/workflows/release.yml
  • actions/checkout v3
  • actions/setup-node v3
  • actions/cache v3
npm
package.json
  • bencode ^4.0.0
  • bitfield ^4.1.0
  • debug ^4.3.5
  • rc4 ^0.1.5
  • streamx ^2.15.1
  • throughput ^1.0.1
  • uint8-util ^2.2.2
  • unordered-array-remove ^1.0.2
  • @webtorrent/semantic-release-config 1.0.10
  • semantic-release 21.1.2
  • standard *
  • tap-spec ^5.0.0
  • tape 5.7.5

  • Check this box to trigger a request for Renovate to run again on this repository

An in-range update of standard is breaking the build 🚨

Version 11.0.0 of standard was just published.

Branch Build failing 🚨
Dependency standard
Current Version 10.0.3
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

standard is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push The Travis CI build failed Details

Commits

The new version differs by 50 commits.

There are 50 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

How the contract works?

Hey friend. I have a P2P wire protocol question.

I have been building my own implementation. I have been simulating responses from other P2P programs to test and I can’t get passed the handshake. I get a handshake:

bufferSize!: 68
Protocol type: BitTorrent protocol
infoHash: aff8bda8adebdab34e1af9ac648bd93c13ed6344
peerId: 2d4c54313030302d764874743153546a4d583043

Then I try sending a handshake back or a interested or any other code...
Do you have any advice?

Thanks,
Connor.

P.S. - you have something very strange in my mind...
You set the protocol buffer like this: '\u0013BitTorrent protocol'
But that's strange in my mind because it should be \u0019. The string is 19 bits! So how does your implementation even work?! You must be getting the majority of success from ws rather then tcp.

TypeError: Cannot read property 'unref' of undefined

I'm getting an error from within the bittorrent-protocol module when running a simple WebTorrent download.

/home/lacker/js/node_modules/bittorrent-protocol/index.js:617
    if (this._timeoutUnref && this._timeout.unref) this._timeout.unref()
                                            ^

TypeError: Cannot read property 'unref' of undefined
    at Wire._updateTimeout (/home/lacker/js/node_modules/bittorrent-protocol/index.js:617:45)
    at Wire._callback (/home/lacker/js/node_modules/bittorrent-protocol/index.js:602:52)
    at Wire._onPiece (/home/lacker/js/node_modules/bittorrent-protocol/index.js:507:10)
    at Wire._onMessage (/home/lacker/js/node_modules/bittorrent-protocol/index.js:673:21)
    at Wire._write (/home/lacker/js/node_modules/bittorrent-protocol/index.js:591:12)
    at doWrite (/home/lacker/js/node_modules/bittorrent-protocol/node_modules/readable-stream/lib/_stream_writable.js:428:64)
    at writeOrBuffer (/home/lacker/js/node_modules/bittorrent-protocol/node_modules/readable-stream/lib/_stream_writable.js:417:5)
    at Wire.Object.<anonymous>.Writable.write (/home/lacker/js/node_modules/bittorrent-protocol/node_modules/readable-stream/lib/_stream_writable.js:334:11)
    at Socket.ondata (_stream_readable.js:639:20)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at addChunk (_stream_readable.js:263:12)
    at readableAddChunk (_stream_readable.js:250:11)
    at Socket.Readable.push (_stream_readable.js:208:10)
    at TCP.onread (net.js:607:20)

Looks like this._timeoutUnref is set but this._timeout isn't. I'm just creating a client, calling client.add(magnet) on it, and waiting for the "done" event on the response torrent.

An in-range update of readable-stream is breaking the build 🚨

Version 2.3.4 of readable-stream was just published.

Branch Build failing 🚨
Dependency readable-stream
Current Version 2.3.3
Type dependency

This version is covered by your current version range and after updating it in your project the build failed.

readable-stream is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details
  • continuous-integration/travis-ci/push The Travis CI build failed Details

Commits

The new version differs by 11 commits.

  • a8c2df1 Bumped v2.3.4
  • f94381c Fix browser support for util.inspect.custom fix
  • fd1efbf removed saucelabs testing for now
  • fc6db13 Proper fix, soft-detecting there is a custom inspect.
  • 6ec7d8a Revert "Fix tests for Node master / citgm"
  • 7dc90fe Fix tests for Node master / citgm
  • 41a3301 Updated dependencies
  • 56d3087 Updated README
  • b4a83e0 Working on old nodes
  • fa8729c built 8.9.4.
  • 56d9356 add lrlna to readme

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.