webtorrent / bittorrent-protocol Goto Github PK

Anyway to get a notification when the wire closes?

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

Version 2.3.5 of readable-stream was just published.

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.

Your Greenkeeper Bot 🌴

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

🚨 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.

- 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.

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...

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

Version 11.0.1 of standard was just published.

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.

Your Greenkeeper Bot 🌴

Version 2.3.4 of readable-stream was just published.

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.

Your Greenkeeper Bot 🌴

What version of this package are you using?
4.1.6
What operating system, Node.js, and npm version?
MacOS ARM, node v16.19.0
What happened?
error after run npm start: Error: Package subpath './index.js' is not defined by "exports"

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.

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

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

Version 4.9.0 of tape was just published.

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.

Your Greenkeeper Bot 🌴

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.

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.

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.

• fix(deps): update dependency uint8-util to ^2.2.5
• fix(deps): update dependency bitfield to ^4.2.0
• fix(deps): update dependency streamx to ^2.18.0
• chore(deps): update actions/cache action to v4
• chore(deps): update actions/checkout action to v4
• chore(deps): update actions/setup-node action to v4
• chore(deps): update dependency semantic-release to v24
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

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

please remove

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

Hi! L627-L689 and L560-L576 is the most difficult to understand. I don't know how they work. Could you explain it?

Thanks!

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.

Version 11.0.0 of standard was just published.

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.

Your Greenkeeper Bot 🌴