toUInt32 on sizes bigger than 32 bit integers

[thermatk]

Trying to download a torrent with a file of a big size (4.7 GB) results in
TypeError: value is out of bounds
at TypeError ()
at checkInt (buffer.js:784:11)
at Buffer.writeUInt32BE (buffer.js:848:5)
at toUInt32 (/home/thermatk/dev/thermorrent/node_modules/peerflix/node_modules/torrent-stream/node_modules/bittorrent-tracker/index.js:489:7)
at announce (/home/thermatk/dev/thermorrent/node_modules/peerflix/node_modules/torrent-stream/node_modules/bittorrent-tracker/index.js:229:20)
at Socket.eval (/home/thermatk/dev/thermorrent/node_modules/peerflix/node_modules/torrent-stream/node_modules/bittorrent-tracker/index.js:179:9)
at Socket.EventEmitter.emit (events.js:98:17)
at UDP.onMessage (dgram.js:437:8)

There is something in the code around about 64-bit? Is it possible to fix by converting to 64 bit integers? Something should be done :)

[feross]

What torrent client are you using?

[thermatk]

Self-written client that is using peerflix, that is using torrent-stream that is using bittorrent-tracker

[feross]

I think I know what's causing this. There are certain lines of code where we assume the number is 32-bit when it might be 64-bit. For example, see: https://github.com/feross/bittorrent-tracker/blob/master/index.js#L227

It would help if you could share the torrent where this reliably fails. That way I can verify that the fix actually worked. Thanks!

cc @mafintosh

[thermatk]

Actually problem at the beginning is the line 228, where opts.left is 4.7 gb. All others will be problematic in future iterations
You can take any torrent with a big enough file, for example, this one(Sintel in 4K) reliably fails:
https://dl.dropboxusercontent.com/u/40748721/%5Brutor.org%5DSintel.2010.4K.DMRip.x264.DD.DTS.SRT-MaLLIeHbKa.torrent
It was difficult to find free movie that could be shared on github with this problem :)

[feross]

The issue is now fixed, and published as 0.4.0.

[mafintosh]

Hmm just noticed that bignum is a compiled module. @feross how would you feel about making bignum an optionalDependency so that if it fails to install on windows (since native modules on win are a huge pain) bittorrent-tracker would still work on most torrents?

[feross]

Sounds good. I'll do that.

[feross]

Done. If bignum is unavailable, then we just round down to the maximum value that a 32bit unsigned integer can contain. These numbers are only used for tracker stats, so it's not a huge deal to fudge them when the torrent is huge and bignum is unavailable.

[feross]

Oh, forgot to mention: published as 0.4.1.

[mafintosh]

@feross Nice! I'll update my upstream dependents