jlouis / etorrent Goto Github PK
View Code? Open in Web Editor NEWErlang Bittorrent Client
License: BSD 2-Clause "Simplified" License
Erlang Bittorrent Client
License: BSD 2-Clause "Simplified" License
Add UPnP support to the client.
I forgot this totally.
When we are stopping a torrent, we should clean up the torrent
from the mnesia tables. This is currently not done properly.
A thing to think about is who should do the cleanup: It would
be best if it is the process itself I think.
We sorely need a full logging framework for etorrent. Investigate the possibilities.
Requesting more peers is currently not done at all. We only get new peers
when someone chooses to connect and when we periodically contact the tracker.
There might be better strategies.
ince this is erlang it is easy to provide other storage engines than the
default. Some ideas are:
bg.gif 404s, which should be fixed.
This is a fairly important BEP, as I would like IPv6 support to be there quickly.
Basically, we want to take an educated guess based on the current rate with some minimum possible. The change should be fairly simple and fairly small.
I thought I got this done, but it seems I did not, unfortunately. When we go from a leecher to a seeder mode, the old rate sparkline entries should be invalidated so we begin freshly again. We are now reporting leeching values in the seeding values, and this is wrong.
Due to some code restructuring for rebar, the etorrent module is now renamed to be the etorrent_app module. But the console commands should still be called etorrent:Command(Arg, ...). To do this, move the relevant commands back to a etorrent module, which you have to add.
Most of the things at the "top" of the supervisor tree can probably be structured better than it currently is.
Rather than send Pids around like we do now, we ought to use a registry of process IDs via gproc instead.
Some trackers support UDP requests. This is a fairly isolated piece of code
if anyone wants to hack it up. Many of the enormous trackers would be
grateful for us having this support. Furthermore, protocol handling is
erlang at its best!
We lack one.
There is some research you need to do w.r.t piece-size etc, but most of the
basic code for doing this should be here.
There is a number of changes which must be done:
This is definitely a candidate for v1.1, down the road.
The BEP does not seem too hard to implement really.
One of the problems is that you may run out of space. By periodically
checking free space on the disk and the amount of data left to download one
can estimate if we have enough space.
This allows for early warning to log-places, eg syslog and friends. And it
allows for closing torrents when we are close to exhausting the space.
The problem is quite isolated and rather easy to implement.
The storage subsystem is currently a bit naive. It can be optimized easily by changing to writev and readv calls rather than the current construction.
Here is the line I use to grep for the remaining modules:
jlouis@illithid:~/Projects/etorrent/src$ grep -c -- '-spec' *.erl | sort -t: -k2,2 -nr
And think about how to fix it permanently :)
Transmission clients reporting versions TR1930 and TR2040 does not play too well with etorrent. Investigate why these clients provoke supervisor restarts.
Move the pick_chunks code from chunk_mgr into the individual torrent processes. Only commit on the choice in the mgr. This evades a copy of a large gb_set.
Keep track of the pieces we have chunked currently. This number is small, so search with these as the iterator rather than the full piece set a peer has.
Implement the histogram. Two ETS tables: {{Torrent, PieceNo}, CountSeen} and {{Torrent, CountSeen}, [PieceNo]}. The latter is an ordered_set. Store the least CountSeen we know is there by an ExplicitMin functor on the structure. Search is by ets:next on {Torrent, CountSeen} until the torrent Id changes. If a piece has a count greater than THRESHOLD, it is abundant and can just be picked outside the histogram.
A simple etop call shows that the clear CPU-hugger is the etorrent_chunk_mgr. Use eprof on this process and figure out where it spends its time. This will probably lead to effective optimization oppurtunities.
Implement scraping for trackers. We are going to use it later on, I am
sure. Also, research where it needs to be used, because I have not done so yet.
The install steps dont mention that you require rebar to be installed, it isnt a big deal but probably worth documenting or just packaging rebar
The currently weakest part of etorrent is the FS subsystem tied to
torrents. It sometimes takes some dives and crashes because of some race
conditions between processes in it. It can be fixed easily, but it will
take some time to do.
The change is not planned right now but rather for some later time.
In particular, it can run out of file descriptors, due to the way the system is created. We should definitely add some way of maintaining a LRU-list or something such.
Some of the oldest code I wrote in the project. It looks like crap. Fix.
This extension is a preliminary for many other extensions. So getting it right is fairly important.
Right now, every piece message will induce a message-traverse through the whole system. That means messaging for each 16KB we get in. I'd rather want to gather up PIECE messages if they can be seen as a bundle.
A bundle is a set of successive chunks. They are easy to detect. Several advantages are possible with this optimization: There is less work to do and when there is work to do we can scatter-gather process it in one fell swoop.
We are currently not sending completed messages to the tracker, which is utterly wrong. We should fix this ASAP.
This issue have two main tasks. One is to support the partial downloading of files inside a torrent. The other is to support the extension so you can tell other clients and the tracker you don't intend to download all files.
Rather, we should use monitors to track that the peer is dead in the processes and then remove the state. It has better code locality, and it is the right way to do things(TM).
Some DHT code is already there by klaar, so we are already partway to the goal.
The peer slot releases should be running on monitors rather than on the current setup where a peer cleans up after itself. It is a safer model.
Check out some of the work astro has made. Perhaps he has one :)
It would be really nice to have this as a DHT if needed.
This is a pure fun bragging project. Make etorrent hot-code upgrade itself
by having it download its hot upgrade and then deploy it on itself. Would
be fun to have for pure show-off.
There seems to be a problem with incoming connections. Investigate this problem and fix it.
To support both BEP 12 and BEP 15 at the same time, some code is needed which does this correctly. Currently, we have a BEP ready which describes the interplay.
This is probably due to a calculation bug and should be fixed.
Here is the error from the shell:
12> etorrent:l().
Id: total left uploaded downloaded I C Comp.
** exception error: bad argument in an arithmetic expression
in function etorrent_rate:eta/2
in call from etorrent:'-list/0-fun-0-'/2
in call from lists:foreach/2
in call from etorrent:list/0
Currently, the rate management code returns the wrong data since the same rate is pushed twice into it. This should be fixed, but while one is there, it could be beneficial to document the process and to make sure there are no other bugs hiding along.
If a torrent is duplicate or tries to access a file another torrent has,
things go completely awry. Must be remedied by looking at what files are
there in the system and handling it gracefully.
Support global bandwidth limitation.
This is done by a basic Weighted Fair Queue algorithm. Easy as hell to pull
off.
Currently, when we go from a leeching to a seeding state, we just keep the sparklines there. We ought to clean out the sparkline as well so we can get the right values from the beginning. Right now you have to wait 25 minutes for the sparklines content to disappear.
How would you feel if your bittorrent client could IM you whenever a
torrent completed? How would you feel if your client could be directed by IM's?
Add IM support to etorrent.
Idea from Joe Armstrong.
Add RSS Feed support to etorrent.
Reported by Dale Harvey:
parsers is undefined
[Break on this error](function%28$%29{$.extend%28{tablesorter:new...g Zebra widget",time%29;}}});})(jQuery);
Or in general: Add UDP/TCP hole punching. Other clients support this
and it shouldn't be hard to add. Seems there are no BEP for it yet though :/
For some reason, this module hid under the radar when we spec'ed modules. Fix it by writing specs for it.
We are currently continuing much above the limit of 8. This ought to be fixed.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.