Free peer to peer downloading software for linux

Batch Download is a plugin for Firefox that makes downloading multiple images easy.

Like FlashGets batch download,but special designed for some image site!

You will find it very useful when you download some url like

http://www.google.com/1.jpg
http://www.google.com/2.jpg
http://www.google.com/3.jpg...

or some other urls like:

http://www.google.com/0102.jpg
http://www.google.com/0203.jpg
http://www.google.com/0304.jpg...

And also you can download all images in current page at once.

Downloads in Tab is an extension which opens "Downloads" manager in tab from Tools menu.

Opens "Downloads" manager in tab from Tools menu or automaticlly when a download starts, when in options you uncheck "Show the Downloads window when downloading a file"

To use tab, in Firefox Options dialog uncheck "Show the Downloads window when downloading a file"

To use window, in Firefox Options dialog check "Show the Downloads window when downloading a file"

To use neither, disable or remove this extension and in Firefox Options dialog uncheck "Show the Downloads window when downloading a file" which will restore original functioning.

PeerProtect is an addon for Jays firewall that generates a file which contains all IP addresses from the RIAA and MPAA, etc. and will protect peer-to-peer programs from them. The Database can be copied from PEERGUARDIAN or IPPREFIX.

MUTE File Sharing is a peer-to-peer network that provides easy search-and-download functionality while also protecting your privacy.
It compiles as a fast, native application for many platforms (no Java, no Python, etc.).
MUTE protects your privacy by avoiding direct connections with your sharing partners in the network. Most other file sharing programs use direct connections to download or upload, making your identity available to spies from the RIAA and other unscrupulous organizations.
MUTE is based on research, and experiments show that it works quite well. MUTEs ant-inspired routing is light-weight, robust, and adaptive. Results from experiments in real MUTE networks show that the collective behavior of MUTE nodes quickly finds the shortest (or fastest) routing path between two nodes on the network.
Enhancements:
- This release fixes bugs in MUTEs initial connection to the network upon startup.
- MUTE has also been upgraded to Crypto++ 5.4, so it should now compile using GCC 4.1.

JVending project bridges P2P networks and wireless delivery of content to mobile devices. Due to high latency of wireless connections, it is not practical to directly hook up the mobile devices to the peer network, so I have taken a different approach with JVending.

A user sets up a personal provisioning server on their PC and hooks it into the network. Through the P2P network, we create a federation of provisioning servers. The mobile devices use the federated provisioning servers as content portals.

JVending differs from P2P systems, such as Gnutella or "Project JXTA" reference implementation, in the following ways. JVending provides:

1. Catalog management
2. Device detection, which delivers the appropriate content based upon the type of browser or device
3. Web based browsing of content, so you can share with your friends on a wired or wireless network, after you have already collected the content.
4. The ability to search for and distribute packaged archives on the peer network.
5. Web links tying together the network.
6. PPG integration for pushing content to mobile devices.

For 2005 - 2006, the major goals of JVending (roughly in order of importance) are:

1. Expanding P2P support, including more in the area of wireless messaging (SMS)
2. JSR-124 compliance
3. Performance testing and monitoring capability
4. Multimedia server and J2ME support. This covers full integration between the MMS Client and the provisioning server.

Setting up the Environment

Follow these steps:

1. Make sure that you have J2SE 1.4.2 JDK installed. If not, go to http://java.sun.com/j2se/1.4.2/download.html and download and install the JDK (not JRE). I have not tested with J2SE 1.5 JDK, so it may or may not work with that version.
2. Download the jvending-standalone.zip file from the JVending project site.
3. Unzip the file into a directory of your choice, say /jvending
4. Set the JAVA_HOME environmental variable, depending on your OS. In windows, you can do this through the Control Panel/System/Advanced/Environmental Variable: JAVA_HOME =
EXAMPLE: JAVA_HOME=c:Programsj2sdk1.4.2_06

Starting JVending

1. Go to the bin directory and click on the run.bat (for windows) or run.sh for Unix.
2. The first time you start JVending, you will see a JXTA Configurator screen show up. Type in your user name and password/verify password. Click OK.
3. Wait 10 seconds for JVending to finish its startup sequence and then go to http://localhost:80/jvending/login. If you get a 404 error, wait a few more seconds and try again. Login ID/Password: admin/admin. Click "Submit Query" button. You will now see the JVending home page.

apt-zeroconf is a distributed apt-cacher for local networks.
Concept
When running more than one Debian box in a LAN with slow internet access the most often used solution to prevent downloading the same Debian package twice is running apt-cacher or the like on one single machine, a centralized server.
The problem with this solution is, that every machine in the network needs to be configured for this proxy. If it is down, no one can update. If you go to another network, you must tweak your sources.list or apt.conf in order to upgrade, which is quite common nowadays with notebooks and wifi technology.
We would therefore be interested in an automatic and peer-to-peer solution. When there is no apt caching daemon in the LAN, we want to fetch the packages directly from the internet. But if there is one or even more available, apt should automatically use it, without any configuration from the user. This is by the way the reason we called it apt-zeroconf in the first place.
The next question is: Who runs an apt caching daemon? In our first implementation, everyone running apt-zeroconf also shares his apt package cache in /var/cache/apt/archives to everyone in the network.
Now, one might think this could potentially pose a security threat as everyone can offer and distribute debs without any authentication whatsoever. This is not the case as we are not yet caching the package lists or pdiffs, which are PGP-signed and contain MD5, SHA1 and SHA256 checksums of the packages. But due to the trusted PGP signatures, caching package lists shouldnt be an issue.
Technical Details
Apt-zeroconf consists of two parts: a http server and the avahi-related stuff. Avahi is used to let everyone else in the network know that you have an apt-zeroconf caching service installed and running. The httpd does act as http server if used in fake-mirror-mode, but also as http proxy if youre using it as such with apt. It uses port 1618 by default.
In every mode, apt-zeroconf is provided with a fallback mirror by apt, so if there are no apt-zeroconf instances on the LAN offering your deb, your regular Debian mirror will be used to provide apt with the necessary files. See Configuration for details.
Configuration
Configuration is done automatically by installing apt-zeroconf. You can disable apt-zeroconf through debconf (dpkg-reconfigure apt-zeroconf) and configure it to your liking. The default configuration is Proxy Mode.
Please note that you just need to carry out the following steps if you didnt activate apt-zeroconf through debconf. These modes are just listed for advanced usage.
Proxy Mode
Add the following line to your /etc/apt/apt.conf:
Acquire { http { Proxy "http://127.0.0.1:1618"; } }
This way every mirror listed in your sources.list will be cached. If you dont want this use the second method.
Fake Mirror Mode
Change in your /etc/apt/sources.list
deb http://your.mirror.debian.org/debian sid main
to
deb http://127.0.0.1:1618/your.mirror.debian.org/debian sid main
e.g. deb http://127.0.0.1:1618/ftp.de.debian.org/debian sid main
With this method, you can select only specific mirrors to be patched through apt-zeroconf.
NOTE: This mode is to be removed! Can also be configured through apt.conf!
Enhancements:
- A new and improved initscript was written.
- Permissions of the logfile and runfile were fixed.
- avahi restarts are handled properly.

Hydranode Core is a modular, plugin-driven peer-to-peer client framework which is designed with true multi-network downloads in mind.
Hydranode Project can be used directly via the built-in shell functionality, or via external user interfaces.
To achieve the large number of features described in the previous section, HydraNode core needs to be extendible without causing feature bloat and increase in system requirements resulting from that. The only way to accomplish that is make the application completely modular - only a minimum set of features are provided by the core application; the rest of the features are implemented by optional loadable modules. Each file-sharing network should be in a separate module, as should be other additional features like e-mail notifications. With this design, the features are de-coupled from each other, thus greatly simplifying the debugging process, and allowing end user to select only the features he or she needs instead of what a programmer thought was best for him or her.
Second most important pre-requisite for a modern peer-to-peer application is platform-independence. The biggest differences in platforms are the graphical user interfaces, while the underlying structure of operating systems is rather similar. To achieve maximum portability, the core application should be decoupled from graphical user interfaces, which then could be written platform-dependently for each target platform; native user interfaces always perform better than interfaces designed for running on large number of platforms. To achieve this, the core application should not have any interactive graphical user interface of its own at all - it should only provide a protocol through which native graphical user interfaces and other application could communicate with it and control it. The protocol itself should be in human-readable format, but also be easily parse-able for client software; the reason for this would be to allow the possibility of interacting with the protocol directly through simple software like telnet, which would greatly simplify debugging process, but could also be useful even for end users as a crude remote control mechanism.
Related to the above comes the question of programming language to use for writing the core application. At this, C++ would be the most sensible choice, because it is widely used across all platforms and provides fastest code (which is required to achieve low system requirements); it allows (and even enforces) object-oriented design, and is easier to understand than C code. Additionally, since HydraNode strongly relies on module-writers, C++ coders are far easier to find than, say, Java coders.
As mentioned in previous section, quickest way to rapid development process is to give the users free access to the source code of the application; it increases possible developer/debugger-base significantly. Out of the myriad of open source licenses out there, GNU General Public License is most respected among users and developers, so HydraNode source code should follow the trend and be licensed under GNU GPL. Having the source code licensed under GNU GPL also allows us to use the almost infinite amount of existing code freely available through the internet, which could prove as a very useful option.
With the fore-seeable future of large number of co-developer base, it is necessary to clearly define the coding standards for the core application. Coding style is very personal; having large number of developers modifying the code will quickly lead to a mix of different styles and personalities, which in turn makes the code less readable, and thus less maintainable. There are several widely accepted coding standards floating around, and for this project we have chosen to use Linux Kernel coding standard; while originally written for C, the concepts still mostly hold for C++. Source code, however, is worth nothing without correct documentation which would give the future co-developers hints on what the original developers had in mind while writing/designing the application. Again, there several widely accepted documentation standards, out of which perhaps the most common is Doxygen-style. The reason behind this is that Doxygen is capable of extracting documentation from source files and generating web pages out of it, which can give a very quick and extensive overview of the entire application at a glance - something future developers will greatly appreciate.
The privacy of the user should be a serious concern for any modern peer-to-peer application developer; there are several institutions which tend to have a habit of spying upon the users and invading their privacy. The simplest solution would be to block the IP addresses of those groups; even better solution would be to simply stay off their radar. The first part can be implemented within the core application since it controls the low-level networking functionality; second part can be implemented by networking plugins depending on the specific networks.
Since the core application will eventually have a large number of very different networking plugins, we have the problem of bandwidth management. The end user shouldnt be bothered with each specific plugins bandwidth limiting settings, so the bandwidth limits should be managed by the main application, which in turn could either allow or deny requests for bandwidth to modules. This setting should be fully configurable, allowing end user to either have the bandwidth shared equally among the plugins, or in favor of one or several specific plugins.
Various file-sharing networks use very different files identifying methods - most often this is a checksum of the file, sometimes accompanied by file size; additionally, there is files meta-data, which can help the end-user identify the file. Since this feature is common to all file-sharing networks, while only differing in the actual checksum used, it should also be handled by the core application. Several points must be considered here - the core application should be able to generate a large number of checksums and store them. It should also be capable of extracting meta-data of files, as well as do cross-references with checksums - given a checksum from one network, it should be able to find the same file on second network (provided the file is known). However, no single client can know the checksums of all files of all networks, which means that the cross-referencing functionality will be of little use locally - this needs a central database which could store the checksums of all files from all networks, and provide cross-referencing functionality. Heres where Myradin comes in - it does exactly that. While support for Myradin shouldnt be completely integrated since it isnt really a part of the application, it could be an optional plugin that retrieves and submits checksums to the central database.
The last feature is far more important than is obvious on first impression; this is the feature that will eventually allow real multi-network simultaneous downloads of same file. The problem is - since each network uses different checksums for files, it is impossible to identify the same file on two separate networks - you dont know the file is the same until you have downloaded the entire file and generated a checksum out of it. However, with a central database which stores checksums of different files from multiple networks, it would be possible to retrieve the checksums of a file on all other networks provided you have the checksum of a file from one network, thus allowing downloading the same file from two or more networks simultaneously. Upon completition, files actual checksum could again be tested against all known checksums to provide even higher corruption protection than single-network downloads. The central database would also contain files meta-data, which would allow end-users to more clearly identify fake files, thus improving the overall quality of files on all file-sharing networks.
Enhancements:
Graphical User Interface (NEW) (madcat)
- Supports search, download and shared files lists
- Lists loaded modules
- Shows networking statistics
- Lists eDonkey2000 server list
Core/GUI communication (NEW) (madcat)
- Supports networking, files, modules and custom data syncronization with user interface(s).
Hydranode Base (madcat)
- No longer writes ANSI color codes to logfile
- Portability to platforms without stdint.h header
- Portability to unix variants without execinfo.h header
- Full support windows XP Service Pack 2 (half-open connections limiting)
- Using hand-crafted event multiplexing system in sockets to bypass the slow Boost.Signals
- Fixed issues with >2GB files on Windows
- Fixed issues with UDP packets handling when multiple packets arrive with short interval (previously this caused the socket to become dead)
- Support for more than 64 concurrent open connections on Windows
- Handles some race conditions in networking, where events come from backend when frontend has been destroyed more gracefully
- Now remembering total downloaded/uploaded/uptime across sessions (global)
Hydranode Core (madcat)
- No longer allocates disk space when shutting down
- Cleans up filename of invalid characters when starting downloads
- Fixed uploading issues while moving completed download to incoming
- Uploaded amount (for shared files) is now properly stored across sessions
- Avoids duplicate scanning of already-scanned directories
- Fixed crash when download is canceled while chunk hash job is in progress
- Added dynamic module-based upload-speed scaling based on modules overall upload/download data ratio, thus upload-capable modules that have downloaded 70% of data get 70% of upload slots. Note that these are not hard limits, so actual results may vary depending on various conditions.
- Faster and non-blocking disk space allocation for downloads
- Fixes crashes when search result handlers get destroyed
- Properly updates file modification date after movework finishes
- --disable-colors and --transform-colors command-line options
- --module-dir command-line option
- Now correctly handles temp/shared dirs with .. in path names
- No longer shares desktop.ini, thumbs.db and similar files
- No longer loses custom metadata after file rehash
Bittorrent Module (madcat)
- Fixed links command for single-file torrents after restart
- Reduced outgoing client connection timeout from 30s to 5s
- Fixed an issue with URI delimineters not being encoded in tracker GET request (ticket #225).
- Handles tracker responses sent with
newline instead of
- Properly seeds downloaded torrents after completition
- Cleans up cache folder on download completition or canceling
- Properly urlencodes HEAD / GET request arguments (ticket #235)
- Listening ports are now restarted instantly after runtime configuration changes
- Fixed some crashes during torrent completition
- Multi-tracker support
- Fixed uploaded/downloaded ratio calculation
eDonkey2000 Module (madcat)
- Reduced outgoing client connection timeout from 30s to 5s
- Fixed parsing QueueRanking packets from MLDonkey clients
- Fixed a bug where client would be dropped after download session end, when the remote client contacted us and sent AcceptUploadReq, and we didnt send ReqFile.
- Now properly destroys remote LowID clients if we are also LowID.
- More default (hardcoded) servers
- Support for global searching
- Miscellaneous protocol performance improvements and fine-tuning
- Properly switches sources to other files on download completition now
- GlobGetSources v2 packet is sent with different opcode. This raises UDP source queries effectiveness by ~5 times (from 4% to 20+%)
- Better A4AF handling
- Listening ports are now restarted instantly after runtime configuration changes
- Setting ed2k/FindServers can be set to 0 now to disable receiving servers from clients and servers
Email notifications (madcat)
- Fixes unhandled exceptions from connect() call (ticket #217)
HLink application (madcat)
- Its now possible to pass full paths (to .torrent files etc)