GreylinkDC++ Mod Extended Pack 2.2.3 (2011) PC

Язык интерфейса: Multi включая Русский
Таблетка: Не Требуется

Системные требования:
► Операционная система: Microsoft® Windows 98SE/me/2000/NT/XP/2003/Vista/7
► Платформа:32 bit
► Процессор: 2Ghz AMD or Intel Pentium 3
► Оперативная память: 512 mb (желательно 1 ГБ)
► Свободное место на жёстком диске: 100 mb

Описание: Клиент P2P-сетей типа Direct Connect.
Клиент GreylinkDC++ - лидер среди DC++ клиентов. Он первый открывает вам уникальные возможности, которые появятся в других клиентах намного позже. Оптимизирован для работы в ADSL и LAN сетях.

Дополнительная информация:
* Улучшенная стабильность, низкое потребление ресурсов

Использование процессорного времени при нахождении на хабах с большим числом юзеров значительно ниже (в сравнении с другими клиентами). Потребление памяти также немного ниже. Работа над оптимизацией кода продолжается.

* Восстановление недокачаных или повреждённых файлов

Из меню "Файл" выбирается "Восстановление файла", указывается правильный MAGNET-линк и расположение поврежденного файла. Как только будет найден источник (пока "поиск альтернатив" лучше сделать вручную из очереди закачек, автопоиск долго ждать), будет скачана карта сегментов файла, произведена проверка сегментов и докачка сегментов, у которых TTH не совпадает с файлом источника.

* Шифрование личных сообщений

Возможно шифрование личных сообщений. Требуется обменяться открытыми ключами (свой публичный ключ можно посмотреть на странице настроек "Сообщения", публичный ключ другого пользователя нужно внести в его свойства в окне "Избранные пользователи"). Сообщение, зашифрованное другим пользователем с помощью Вашего публичного ключа, можно расшифровать лишь вашим секретным ключом или секретным ключом отправителя. Администраторы хабов не смогут прочитать зашифрованную переписку. Расшифрованные сообщения отмечаются красным цветом в метке времени получения. Для шифрования используется метод Diffie-Hellman-а с длиной ключа 64 бита.

* Возможность объединить файлы с разных каталогов/дисков в одну папку шары

При расшаривании нескольких папок нужно дать им одинаковое имя в шаре. Таким образом, файлы (например, фильмы) можно хранить на разных дисках, а для юзера они будут в одном общем списке. Другое применение: внутреннее разделение файлов (например, "смотрел", "на запись", "записано" и т.п.) по папкам так, что юзер это в конечном итоге не видит.
Любой расшариваемый каталог в любой подкаталог шары. Например, отмеченной в шаре папке Heroes_s3 можно дать виртуальное имя Movies/TV-Show/Heroes/Season 3 (слешы в другую сторону тоже работают).

* Сохранение открытых окон ЛС и выданных слотов при перезапуске клиента

При перезапуске клиента в случае ошибки, или при необходимости временно отключить файлообменник, история слотов и сообщений восстановится к моменту следующего запуска. Таким образов, можно смело выдавать слот на неделю, а также не бояться выйти из сети, оставив ЛС без ответа.

* Хранение карты сегментов файла (TTH-дерева) в отдельном NTFS-потоке с именем .gltth

Что это даёт? Не нужно тратить время на повторное хеширование, если:

1. Завершена скачка большого файла и вы планируете его расшарить

2. Большой файл переносится в другое место, или временно убирается из шары и потом добавляется. Если файл копируется, а не перемещается, то сохранение потока лежит на совести копировщика (Windows-проводник и FAR в режиме "Use system copy routine" сохраняют все потоки)

Слишком мелкие потоки создавать расточительно из-за выделения места на диске целыми кластерами, поэтому поток создаётся для файлов размером от 16MB и выше.

Фича занимает на диске не более 384 килобайт с каждого гигабайта большого файла, отключается в закладке Advanced.

* Улучшен авто-поиск источников

Периодически клиент dc++ посылает поисковые запросы на один из файлов в очереди.
Пользователи, расшарившие файл, добавляются в список источников файла, у них скачивается файл-лист и проверяется, нет ли в листе других файлов, тоже находящихся в очереди.
greylink'овский "менеджер файл-листов" расширяет эту функциональность следующим образом:

- Ведется история файл-листов, скачанных за последний час.

- При нахождении автопоиском файла у некоторого пользователя (например, при добавлении новой закачки в очередь) проверяется, не

качался ли файл-лист пользователя за последний час. Если качался, остальные файлы ищутся в скачаном листе. Если не качался, файл-

лист помещается в очередь закачек.

- Если файл найден у одного пользователя на нескольких хабах, скачивается файл-лист только с одного хаба, к закачке создаются

источники с этого пользователя на всех хабах.

* Частично устранена проблема падения скорости к завершению закачки

Все dc++-клиенты (по крайней мере, по состоянию на 24.06.2007), не позволяют докачивать последний сегмент файла с нескольких пользователей. В greylink этот момент наступает намного позже, тем самым значительно ускоряется докачка больших файлов (например, DVD-образов). В новых версиях это направление (улучшение скорости докачки) будет дальше дорабатываться.

* Создание magnet-ссылок на каталоги

Способ 1

В меню "Файл" выбираем "Получить TTH каталога...", выбираем каталог. Копируем магнет-ссылку. По этой магнет-ссылке пользователи смогут найти каталог в шаре пользователя greylink, если он имеет аналогичное содержимое, как в той шаре, где сделана ссылка. Имена файлов не влияют на хеш, важны только структура подкаталогов и содержимое файлов (то есть, файлы можно переименовывать, но нельзя изменять, добавлять, удалять, перемещать в подкаталоги файлы, чтобы ссылка не изменилась)

Способ 2

Открываем свой список, на нужном каталоге из контекстного меню выбираем "Generate sublist". Получается файл с расширением .dcls Раздаём всем magnet-ссылку на этот файл. Когда кто-то скачивает файл в greylink, он автоматически открывается и можно выбрать "Download/DownloadTo" на каталоге верхнего уровня (а можно и на любых других каталогах/файлах). Автоматическое добавление содержимого .dcls в очередь закачек не сделано, чтобы защититься от недобросовестных пользователей, которые будут подкладывать вглубь своей шары файлы со ссылками на всякий ненужный мусор.

* Установка приоритетов на раздачу файлов

Задайте группы файлов и для каждой группы установите число дополнительных слотов отдачи. Если все основные слоты заняты и клиент пробует скачать файл из группы, выделяется слот из резерва группы. Таким образом, вы можете выразить свои предпочтения, что будут скачивать с вас в первую очередь. Некоторые группы могут быть настроены так, чтобы при запросе файла из группы не применялся авто-бан (по размеру шары и т.п.), не применялось ограничение скорости (Ограничение скорости = SU) или применялось заданное в кБ/сек ограничение.

При желании пользователя группы с картинками и слотами (второе-опционально) отображаются в файл-списке. Так что другие пользователи сети смогут увидеть, какие файлы получить легче (если вы разрешили экспорт групп в файл-лист и просмотр листа осуществляется с помощью greylink).

* Улучшена наглядность списка отдаваемых файлов

Для каждой отдачи отображается значок причины разрешения отдачи.

* Поддержка кодировки UTF-16 при передаче магнет-ссылок из браузера

Примеры ссылок, которые неправильно перехватываются другими DC-клиентами из Internet Explorer (портится название файла)
Робокоп-2.avi Робокоп-2.avi

* Набор заранее заготовленных сообщений для чата

Составляется в файле Settings/CustomMessages.ini. Сообщения, которые начинаются со знака '$', отсылаются сразу и не изменяют содержимого строки, в которой набирается сообшение.

* Загрузка содержимого папки из окна поиска

Позволяет быстро посмотреть содержимое определённой папки из строки поиска, на закачивая весь файл-лист.

* Продвинутые настройки избранного хаба

Полностью переписано управление настройками. Для хаба можно переопределить абсолютно любую настройку (за исключением глобальных: шара, ограничения скоростей), от параметров подключения и формата логов до цветов и звуков. (При настройке избранного хаба открывается привычный диалог с настройками клиента, в котором выбираются индивидуальные настройки хаба). Совместимость файла настроек с предыдущими версиями и другими клиентами только односторонняя.

* Разные шары на разных хабах

Интуитивно понятно настраивается из свойств Избранного Хаба на странице шары. Также можно подключить чей-то файл-лист и выдать за свой.
При использовании отдельного файл-листа действуют правила:

- Если в шаре не окажется файла, который есть в списке файлов, greylink на попытку отдать файл будет реагировать сообщением "нет

слотов", что можно использовать для более эффективной подделки шары, чем генерация случайных файлов. Скачав чей-то файл-лист

и указав его в качестве используемого, получим хорошую шару. Если в реальной шаре будут файлы из поддельной, то они будут

отдаваться, что ещё сильнее запутает модераторов хаба

- Перечитывание содержимого файлов происходит по команде "обновление шары", поэтому важно инициировать обновление после

замены файлов.

* Соединения между клиентами через сеть, отличную от сети хаба

Типичные сценарии, когда IP прямого соединения не должен совпадать с тем IP, который отправлен хабу:

1. Хаб доступен обоим клиентам, но клиенты между собой напрямую не могут подключаться (только через VPN и т.п.)
2. Хаб находится в локальной сети, но доступен из интернета и хочется настроить файлообмен с интернет-пользователем
3. Клиент подключен к нескольким локальным сетям с перекрывающимися адресами

Как это работает:
Клиенты должны обменяться информацией, в каких сетях они находятся и своими IP-адресами в каждой сети. Для этого пользователи назначают сетям идентификаторы (придерживаясь одинаковых соглашений, например, сеть на VPN-сервере vpn.conn.ru и порту 111 назовут vpn://vpn.conn.ru:111 или просто conn-vpn, лишь бы у всех называлась одинаково). Информация о сетях может выставляться в поле "описание" хаба или, если на хабе запрещены такие описания, строка с конфигом сети вручную передаётся в личку командой /net - клиент на другой стороне автоматически распознает конфигурацию
После этого, если клиенты находятся в одинаковых сетях, они используют заданные IP-адреса внутри сети для соединений между собой.

Примеры настроек для рассмотренных выше случаев:

1. Хаб доступен обоим клиентам, но клиенты между собой напрямую не могут подключаться
Клиент заполняет конфиг сети строкой: "vpn.conn.ru=192.168.17.6,world=89.110.55.13"
где 192.168.17.6 - адрес, выданный сервером vpn.conn.ru, 89.110.55.13 - адрес, доступный из интернета (для данного примера это не нужно, но пригодится в следующем)
2. Хаб находится в локальной сети, но доступен из интернета и хочется настроить файлообмен с интернет-пользователем
Хаб видит адрес пользователя как 10.0.3.6 (а то и 127.0.0.1, если установлен на машине пользователя), но этот адрес не подойдёт для внешних подключений. Поэтому пользователь сети 10.0.3.x прописывает у себя строку "world=89.110.55.13", а интернет-пользователь - строку "world=0.0.0.0", указывая, что он подключен к сети с меткой "world", но IP-адрес не нуждается в преобразовании.
3. Клиент подключен к нескольким локальным сетям с перекрывающимися адресами

Проблема описана в следующем письме:

Есть 2 сетевые карты, к которым подключены Сеть1 и Сеть2 с компьютерами имеющими одинаковые адреса. Такие компьютеры не могут быть одновременно доступны для обмена информацией, поэтому приходится делать выбор какие адреса оставить для обмена, добавляя соответствующие маршруты. Но попытаемся обойти это ограничение и на Интерфейсе1 между Сеть1 и нашим компьютером поставим роутер под Linux. Когда ему приходит пакет, например с диапазона 10.10.x.x (конфликтующий), он заменяет в поле адреса пакета 10.10.x.x, допустим, на 10.20.x.x (свободный не конфликтующий). Наш компьютер в результате думает, что ему пришел пакет из Сети1 с адресом отправителя 10.20.x.x. Он его обрабатывает и отсылает назад, а мы прописали в роутинг, что шлюз для 10.20.x.x - Интерфейс1 (Сеть1). Роутер на выходе ловит пакет и проводит над ним обратную операцию - заменяет 10.20.x.x на 10.10.x.x и шлет дальше в Сеть1. Т.е. мы делаем SNAT на роутере под linux, исключая конфликт адресов. Однако при заходе в Сети1 на DC++ хаб последний передает список всех присутствующих и их реальные IP адреса. И наш DC++ клиент будет пытаться соединиться именно с теми адресами, которые дал ему хаб, не производя замену. Для нормальной работы клиента требуется указать в свойствах хаба заменять IP адреса, которые он передает, на свои по определенному правилу: в данном примере 10.10.x.x на 10.20.x.x. Т.е. в свойствах хаба в разделе "Connection settings" в поле "VPN and networks config" добавить возможность указывать строки вида "conv1=10.10.0.0/16~10.20.0.0/16", "conv2=192.168.0.0/20~192.168.100.0/20" и т.д. для каждого конфликтующего диапазона.

В данном случае необходимо прописать правило 10.10.0.0/16~10.20.0.0,192.168.0.0/20~192.168.100.0
Не забывайте также преобразовывать адреса UDP-пакетов, чтобы поисковые ответы уходили в другую сеть. Для такой схемы нужно использовать пассивный режим.

* А также...

Отображение частичных (у которых файл в процессе скачивания) источников в поиске
Анимированные смайлы.
Красивый прогресс хеширования в главном окне программы.

Много улучшений интерфейса, идеи которых мы собрали на разных форумах. Ищите, пользуйтесь.

История изменений:
· Исправлена ошибка версии 0.41: программа не посылала UDP-ответы на поисковые запросы от NMDC-хабов.

· При переименовании файла в очереди скачивания (кнопкой F2) выделяется имя файла без расширения.

· Обновлен файл определения местоположения (GeoIPCountryWhois от 01.02.2011).

· Обновлен АkelPad до версии 4.5.3.

· Обновление MediaInfo до версии 0.7.41.

· Откорректированы хабы.

· Исправлено: команда "Сообщение на все хабы" не посылает текст на хаб, у которого в опциях отключен чат

· В CustomMessages.ini можно использовать команды клиента (такие, как /winamp, /ratio)

· Исправлено: не запоминались порты TCP и UDP (при старте программы выбирались новые)

· Добавлена поддержка SOCKS4 для шлюзов на базе routerOS

· Известные проблемы активного режима NMDC-протокола:
1. SOCKS4-BIND требует указания ip-адреса, с которого поступает соединение, на NMDC-хабах адреса всех юзеров доступны только админам хаба.
2. Т.к. SOCKS4 спасибо, скачал Торрент игру, работает отлично с UDP, нельзя отвечать на поисковые запросы активных юзеров
В пасивном режиме или при использовании ADC-хабов проблем не возникает (IP всех юзеров заранее известны, на активный поиск можно отвечать через хаб)

· Добавлена поддержка хабов в домене .РФ ( хаб.смолнет.рф )

· Возможность настройки фоновой картинки в окне активных соединений

· Отображение параметров медиа-файлов из файл-листов flylink.