Hydranode Project Hydranode Core is a modular, plugin-driven peer-to-peer client framework.
Download

Hydranode Project Ranking & Summary

Hydranode Project Tags

file sharing filesharing P2P client peer-to-peer peer-to-peer framework Hydranode

Hydranode Project Description

Hydranode Core is a modular, plugin-driven peer-to-peer client framework. 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 shouldn't 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. Here's where Myradin comes in - it does exactly that. While support for Myradin shouldn't be completely integrated since it isn't 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 don't 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, file's 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.What's New in This Release: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 module's 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 didn't 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) · It's now possible to pass full paths (to .torrent files etc)

Hydranode Project Related Software