Live data from Hacker News

Show HN: I wrote a BitTorrent Client from scratch

github.com

51–60 of 68 posts

Re: Show HN: I wrote a BitTorrent Client from scratch

#51
post #22
post #17

Earlier quoted context omitted.

[flagged]

Yes, very strange. There's no problem with using AI to build your first app and leaving the generated comments in the code is fine. But the number of comments on this thread that begin "This is so cool" is very suspicious.

It doesn't seem wild to me that people would post "This is cool" on a ShowHN post. I did [here](https://news.ycombinator.com/item?id=44265915), and as far as I'm aware, I'm not an AI.

Would you like more information about how to identify AI comments? (kidding)

Re: Show HN: I wrote a BitTorrent Client from scratch

#52

As a non go developer, may I ask why you're using older go version 1.21? Is there a reason to stay with older releases? EDIT: It seems like it was deprecated 10 months ago

Windows 7 support is one reason to stick to older GoLang releases. A project in Go 1.21.4 or earlier will work on every Windows release and any computer made since 2009, whereas a version bump to v1.21.5 means it will only work on more recent computers and Win10 and 11 for no benefit. https://github.com/golang/go/issues/64622

I think this is a reasonable take. Yes, people shouldn't be running Windows 7 as their daily driver. But if you can support it at basically no effort and without sacrifices that is the right thing to do. Supporting more platforms is a good thing, even if that platform is an old Windows version instead of an Amiga

Re: Show HN: I wrote a BitTorrent Client from scratch

#54

How hard would it be to add a GUI to this? I don't think I've seen a lot of GO Gui implementations in the past

There's a bunch https://github.com/go-graphics/go-gui-projects

My personal favourite is an ImGui wrapper https://github.com/AllenDang/giu

The most featureful is probably unison, although I'm uncertain if anyone uses it outside of their own project (https://gurpscharactersheet.com), meaning documentation will be sparse https://github.com/richardwilkes/unison

Gio uses a different way of thinking about GUIs, used by Tailscale and gotraceui https://gioui.org

Wails is great if you're familiar with development on the web https://wails.io

The GTK4 bindings also look nice https://github.com/diamondburned/gotk4

Cogent Core also looks neat, but I didn't have the time to play with it before I switched over to using the Odin programming language instead of Go https://www.cogentcore.org/core

I personally had nothing but issues with Fyne (especially in regard to performance, across multiple computers and operating systems), but it's probably the most popular option https://fyne.io

Re: Show HN: I wrote a BitTorrent Client from scratch

#55

Great work! Just an FYI, you might want to limit the dynamic allocation size in the bencode decoder: since it's untrusted input (either from torrent or announce), a malicious input could DoS the client by requesting extremely large allocations during string parsing. A good upper bound could be the remaining length of the input, as a well formed torrent can't contain a string longer than the rest of the file.

thanks for pointing this out. I've added this in my to-dos.

You might look into (if you only care about reading it) writing the bencode decoder using Kaitai Struct [0] to avoid some of the common pitfalls.

[0]: kaitai.io

Re: Show HN: I wrote a BitTorrent Client from scratch

#56

As a non go developer, may I ask why you're using older go version 1.21? Is there a reason to stay with older releases? EDIT: It seems like it was deprecated 10 months ago

The README is likely AI-generated. The actual go.mod file lists 1.23.1 as the Go version[1], which implies a requirement of Go 1.23.1 or higher[2].

[1] https://github.com/piyushgupta53/go-torrent-client/blob/6130...

[2] https://go.dev/doc/modules/gomod-ref#go-notes

Re: Show HN: I wrote a BitTorrent Client from scratch

#58

Earlier quoted context omitted.

Windows 7 support is one reason to stick to older GoLang releases. A project in Go 1.21.4 or earlier will work on every Windows release and any computer made since 2009, whereas a version bump to v1.21.5 means it will only work on more recent computers and Win10 and 11 for no benefit. https://github.com/golang/go/issues/64622

I think this is a reasonable take. Yes, people shouldn't be running Windows 7 as their daily driver. But if you can support it at basically no effort and without sacrifices that is the right thing to do. Supporting more platforms is a good thing, even if that platform is an old Windows version instead of an Amiga

> and without sacrifices

There are always trade-offs/sacrifices.

The Go team isn't making new versions just for fun. Each version since 1.21 has had improvements. Especially the fix/change to for loop variables in 1.22 is very nice to have, and helps preventing to write bugs.

If there's a reasonable expectation that users will use outdated platforms, it makes sense to support them. If there is no such expectation at all, why would one forego the improvements to the language and tooling.

There's always a price to pay.

Re: Show HN: I wrote a BitTorrent Client from scratch

#59

Earlier quoted context omitted.

I think this is a reasonable take. Yes, people shouldn't be running Windows 7 as their daily driver. But if you can support it at basically no effort and without sacrifices that is the right thing to do. Supporting more platforms is a good thing, even if that platform is an old Windows version instead of an Amiga

> and without sacrifices There are always trade-offs/sacrifices. The Go team isn't making new versions just for fun. Each version since 1.21 has had improvements. Especially the fix/change to for loop variables in 1.22 is very nice to have, and helps preventing to write bugs. If there's a reasonable expectation that users will use outdated platforms, it makes sense to support them. If there is no such expectation at…

In this case the 'improvements' aren't required for this particular project.

Re: Show HN: I wrote a BitTorrent Client from scratch

#60

what did you refer for building this? did you read the protocol or did you go through other implementations? curious because it always makes me wonder how people build stuff like this from scratch

Interestingly (or maybe not) I started writing a Bittorrent client last week, also in Go. I don't really like AI/LLMs for coding, and my goal is to really learn from it. Not to just deliver some piece of code that an AI wrote...

So the first step is to figure out if there is an actual spec for the protocol. Well, in the case of Bittorrent there is a spec, but it's kinda... brief. Basically, this is the spec: https://www.bittorrent.org/beps/bep_0003.html

There are some additional extensions here: https://www.bittorrent.org/beps/bep_0000.html

It's very important to break the work up in tiny steps that each give some kind of a result. E.g. I started with parsing .torrent files, for which you have to implement bencoding.

That was interesting, because I downloaded the Arch Linux .torrent and found out it was basically incorrect: it has a url-list key which isn't mentioned in the spec. Then you have to go down a rabbit hole of some research trying to find out what the heck is up with that (turned out to be https://www.bittorrent.org/beps/bep_0019.html). Finally, was able to successfully parse the Debian Linux .torrent file.

Then came implementing the tracker Announce HTTP request and the peer protocol. The peer protocol was tricky, and that's when an experimentation mindset comes in handy. I stripped the announce URL from the Debian torrent and loaded it up in KTorrent, that way it wasn't able to find any peers. I used the "Add peer" option to add my client so I could see what messages it was sending me, and alongside I would implement sending those to KTorrent messages too. A lot of trial and error and debugging.

I have to confess that from time to time I had to ask ChatGPT about some small protocol details because they just didn't show up in the spec. There's also a lot of details that clients have implemented over time but which aren't really documented well. Mostly algorithms for which pieces to download, which peers to choose, how to "choke"/"unchoke", etc, is not well-defined. But web searches help out a lot.

Also an honorable mention to https://wiki.theory.org/Main_Page which has some nice information.

I'm now at a point where I can fully download and upload a torrent with my local KTorrent, so the next steps are to actually get peers from the tracker, and some algorithm to download pieces and store them in a file.

Hope this gives some insights. Let me know if you have specific questions about the process.

Post reply on HN