The objections you level against WebRTC DataChannels make it sound like the particular transports you mention are somehow blessed, that it's not and won't ever be bittorrent unless it's TCP or UDP (and even if it was a hard/fast requirement, one could still benefit from WebTorrent via Firefox extensions and Chrome apps). Why so serious? Dial down your zeal friend.īitTorrent is extensible: I see you agree with that premise since you listed UDP sockets, formalized by BEP-0029. Sounds like a whole lot more bellyaching.
You also need to talk to local network devices (UPnP routers), enumerate network interfaces to bind ports to the correct one so you can tell other clients your alternative addresses (this is part of ipv4/ipv6 compatbility) and a whole bunch of other sort of low-level stuff.īrowsers simply do not provide the same access to system APIs. Some torrents also have thousands of files open simultaneously, this can push the number of filehandles the browser process has to keep, possibly conflicting with other files the browser also wants to open, e.g. Additional facilities like mmaped files, epoll-based socket IO and inotify make for more efficient implementations.Ī good bittorrent client on a gigabit connection can push a lot of data around, hashcheck it and so on. TCP and UDP sockets are essential (this thing uses webrtc, so it's not even bittorrent-compliant). Web APIs don't provide the facilities necessary for a complete bittorrent stack. >They both seem like perfectly good places to write a BitTorrent client.Įxcept they aren't.
0 kommentar(er)
