Additional information:

* Improved stability, low resource consumption
The use of processor time when being on hubs with a large number of users is significantly lower (in comparison with other clients). Memory consumption is also slightly lower. Work on code optimization continues.
* Recovery of under-downloaded or corrupted files
From the "File" menu, "File Recovery" is selected, the correct MAGNET link and the location of the damaged file are specified. As soon as the source is found (so far "search for alternatives" it is better to do it manually from the download queue, auto-search will take a long time to wait), a file segment map will be downloaded, segments will be checked and segments whose TTH does not match the source file will be downloaded.
* Encryption of private messages
It is possible to encrypt private messages. It is required to exchange public keys (you can view your public key on the settings page of the Message", the public key of another user must be entered in its properties in the "Selected Users" window). A message encrypted by another user using your public key can only be decrypted with your secret key or the sender's secret key. Hub administrators will not be able to read encrypted correspondence. Decrypted messages are marked in red in the receipt timestamp. The Diffie-Hellman method with a key length of 64 bits is used for encryption.
* Ability to merge files from different directories/disks into one folder.
When sharing several folders, you need to give them the same name in the ball. Thus, files (for example, movies) can be stored on different disks, and for the user they will be in the same general list. Other use: internal file separation (for example, "watched", "on record", "recorded" etc.) by folders so that the user eventually does not see it.
Any shared directory in any subdirectory balls. For example, the Heroes_s3 folder marked in the balloon can be given the virtual name Movies/TV-Show/Heroes/Season 3 (slashes in the other direction also work).
* Saving open BOS windows and issued slots when restarting the client
When restarting the client in case of an error, or if necessary temporarily disable file sharing, the history of slots and messages will be restored by the time of the next launch. Thus, you can safely give out a slot for a week, and also not be afraid to log out of the network, leaving the BOS unanswered.
* Storing a file segment map (TTH tree) in a separate NTFS stream with the name .gltth
What does it give? No need to waste time on re-hashing if:
1. The download of a large file has been completed and you plan to share it
2. A large file is moved to another location, or temporarily removed from the file and then added. If the file is copied and not moved, then saving the stream is on the conscience of the copier (Windows Explorer and FAR in the "Use system copy routine" mode save all streams)
It is wasteful to create too small streams due to the allocation of disk space by entire clusters, so a stream is created for files of size from 16MB and above.
The feature takes up no more than 384 kilobytes from each gigabyte of a large file on the disk, it is disabled in the Advanced tab.
* Improved auto-search of sources
Periodically, the dc++ client sends search queries to one of the files in the queue.
Users who have shared a file are added to the list of file sources, a file list is downloaded from them and checked to see if there are any other files in the list that are also in the queue.
greylink'ovsky"file list manager" extends this functionality as follows:
- The history of file lists downloaded in the last hour is maintained.
- When an auto-search finds a file from some user (for example, when adding a new download to the queue), it is checked whether
whether the user's file list has been swinging in the last hour. If it swung, the rest of the files are searched in the downloaded sheet. If it didn't swing, the file-
the sheet is placed in the download queue.
- If a file is found with one user on several hubs, the file list is downloaded from only one hub, the following are created for download
sources from this user on all hubs.
* Partially fixed the problem of speed drop by the end of the download
All dc++ clients (at least as of 06/24/2007) do not allow downloading the last segment of a file from multiple users. In greylink, this moment comes much later, thereby significantly speeding up the downloading of large files (for example, DVD images). In the new versions, this direction (improving the pumping speed) will be further refined.
* Creating magnet links to directories
Method 1
In the menu "File" select "Get TTH directory...", select the directory. Copy the magnet link. Using this magnet link, users will be able to find a directory in the greylink user's balloon if it has similar contents as in the balloon where the link is made. File names do not affect the hash, only the structure of subdirectories and the contents of files are important (that is, files can be renamed, but you cannot change, add, delete, move files to subdirectories so that the link does not change)
Method 2
Open your list, select "Generate sublist" from the context menu on the desired directory. It turns out a file with the extension .dcls are distributing a magnet link to this file to everyone. When someone downloads a file in greylink, it opens automatically and you can select "Download/Downloadto" on the top-level directory (or you can on any other directories/files). Automatic addition of content .dcls in the download queue is not done to protect against unscrupulous users who will put files with links to any unnecessary garbage deep into their system.
* Setting priorities for file distribution
Set the file groups and set the number of additional recoil slots for each group. If all the main slots are occupied and the client tries to download a file from the group, a slot is allocated from the group's reserve. This way you can express your preferences, what will be downloaded from you first. Some groups can be configured so that when a file is requested from a group, an auto-ban is not applied (by the size of balls, etc.), a speed limit is not applied (Speed limit = SU) or a limit set in kB/sec is applied.
If the user wishes, groups with pictures and slots (the second is optional) are displayed in the file list. So other network users will be able to see which files are easier to get (if you have allowed groups to be exported to a file list and the sheet is viewed using greylink).
* Improved visibility of the list of files to be given
For each recoil, an icon of the reason for allowing recoil is displayed.
* Support for UTF-16 encoding when transmitting magnet links from the browser
Examples of links that are incorrectly intercepted by other DC clients from Internet Explorer (the file name is corrupted)
Robocop-2.avi Robocop-2.avi
* A set of pre-prepared chat messages
Compiled in the Settings/CustomMessages.ini file. Messages that start with a sign '$', they are sent immediately and do not change the contents of the line in which the message is typed.
* Loading folder contents from the search box
Allows you to quickly view the contents of a specific folder from the search bar by uploading the entire file list.
* Advanced settings of the favorite hub
Settings management has been completely rewritten. Absolutely any setting can be redefined for the hub (with the exception of global ones: ball, speed limits), from connection parameters and log format to colors and sounds. (When setting up a favorite hub, the usual dialog opens with the client settings, in which individual hub settings are selected). The compatibility of the settings file with previous versions and other clients is only one-way.
* Different balls on different hubs
It is intuitively configured from the properties of the Favorite Hub on the balls page. You can also connect someone's file list and pass it off as your own.
When using a separate file list, the rules apply:
- If there is no file in the ball that is in the file list, greylink will respond to an attempt to give the file with the message "no
slots" what can be used to more effectively fake balls than generating random files. By downloading someone's file list
and specifying it as used, we get a good ball. If there are files from the fake one in the real balloon, then they will be
surrender, which will confuse the hub moderators even more
- Re-reading the contents of the files occurs by the command "update the balls", so it is important to initiate the update after
file replacements.
* Connections between clients via a network other than the hub network
Typical scenarios when the IP of a direct connection should not match the IP that is sent to the hub:
1. The hub is accessible to both clients, but clients cannot connect directly to each other (only via VPN, etc.)
2. The hub is located on a local network, but is accessible from the Internet and I want to set up file sharing with an Internet user
3. The client is connected to several local networks with overlapping addresses
How it works:
Clients should exchange information about which networks they are on and their IP addresses in each network. To do this, users assign identifiers to networks (adhering to the same conventions, for example, a network on a VPN server vpn.conn.ru and port 111 will be called vpn://vpn.conn.ru:111 or just conn-vpn, as long as everyone has the same name). Information about networks can be displayed in the "description" field" hub or, if such descriptions are prohibited on the hub, the line with the network config is manually transmitted to the personal with the /net command - the client on the other side automatically recognizes the configuration
After that, if the clients are on the same networks, they use the specified IP addresses inside the network for connections between each other.
Examples of settings for the cases discussed above:
1. The hub is accessible to both clients, but clients cannot connect directly to each other
The client fills in the network config with the line: "vpn.conn.ru=192.168.17.6,world=89.110.55.13"
where 192.168.17.6 is the address issued by the server vpn.conn.ru, 89.110.55.13 - an address accessible from the Internet (this is not necessary for this example, but it will be useful in the following)
2. The hub is located on a local network, but is accessible from the Internet and I want to set up file sharing with an Internet user
The hub sees the user's address as 10.0.3.6 (or even 127.0.0.1 if installed on the user's machine), but this address is not suitable for external connections. Therefore, the network user 10.0.3.x prescribes the string "world=89.110.55.13", and the Internet user - the string "world=0.0.0.0", indicating that he is connected to the network with the label "world", but the IP address does not need to be converted.
3. The client is connected to several local networks with overlapping addresses
The problem is described in the following email:
There are 2 network cards to which Net1 and Net2 are connected with computers having the same addresses. Such computers cannot be simultaneously available for information exchange, so you have to make a choice which addresses to leave for exchange by adding the appropriate routes. But we will try to circumvent this restriction and put a router under Linux on the Interface1 between Net1 and our computer. When a packet arrives to him, for example from the range 10.10.x.x (conflicting), he replaces 10.10.x.x in the packet address field, for example, with 10.20.x.x (free non-conflicting). As a result, our computer thinks that it has received a packet from Net1 with the sender's address 10.20.x.x. It processes it and sends it back, and we have registered in the routing that the gateway for 10.20.x.x is Interface1 (Net1). The router catches the packet at the output and performs the reverse operation on it - replaces 10.20.x.x with 10.10.x.x and sends it further to the Net1. That is, we do SNAT on the router under linux, excluding the address conflict. However, when entering the Net1 on the DC++ hub, the latter transmits a list of all those present and their real IP addresses. And our DC++ client will try to connect exactly to the addresses that the hub gave him, without making a replacement. For the normal operation of the client, it is required to specify in the properties of the hub to replace the IP addresses that it transmits with its own according to a certain rule: in this example, 10.10.x.x with 10.20.x.x. I.e., in the properties of the hub in the "Connection settings" section, in the "VPN and networks config" field, add the ability to specify lines like "conv1=10.10.0.0/16~10.20.0.0/16", "conv2= 192.168.0.0/20~192.168.100.0/20" etc. for each conflicting range.
In this case, it is necessary to prescribe a rule 10.10.0.0/16~10.20.0.0,192.168.0.0/20~192.168.100.0
Don't forget to also convert the addresses of UDP packets so that search responses go to another network. For such a scheme, you need to use the passive mode.
* And also...
Displaying partial (which have a file in the process of downloading) sources in the search
Animated emoticons.
Beautiful hashing progress in the main program window.
There are a lot of interface improvements, the ideas of which we have collected on various forums. Search, use.

Changelog:

* Fixed bug version 0.41: the program did not send UDP responses to search queries from NMDC hubs.
* When renaming a file in the download queue (with the F2 button), the file name without an extension is highlighted.
* Updated the location determination file (geoipcountrywhois from 01.02.2011).
* Updated AkelPad to version 4.5.3.
* Update MediaInfo to version 0.7.41.
* Corrected hubs.
* Fixed: The command "Message to all hubs" does not send text to a hub that has chat disabled in the options
* In CustomMessages.ini, you can use client commands (such as /winamp, /ratio)
* Fixed: TCP and UDP ports were not remembered (new ones were selected at the start of the program)
* Added SOCKS4 support for RouterOS-based gateways
* Known problems with the active mode of the NMDC protocol:
1. SOCKS4-BIND requires specifying the IP address from which the connection is received, on NMDC hubs, the addresses of all users are available only to the admins of the hub.
2. Since SOCKS4 does not work with UDP, it is impossible to respond to search queries of active users
In passive mode or when using ADC hubs, there are no problems (the IP addresses of all users are known in advance, active search can be answered through the hub)
* Added support for hubs in the domain .RF ( hub.smolnet.rf )
* Ability to customize the background image in the active connections window
* Display of media file parameters from flylink file lists.