SetupFlylinkDC-r500-alpha20-build-3342.exe
SetupFlylinkDC-x64-r500-alpha20-build-3342.exe
FlylinkDC-r500-alpha20-build-3342(17-Dec-2009_21_30).zip
FlylinkDC-r500-alpha20-x64-build-3342(17-Dec-2009_22_49).zip
------------------------------------------------------------------------
* Исправлен порта magnetdc, в соответствии с xsd
------------------------------------------------------------------------
r3340 | rain.bipper | 2009-12-17 00:37:34 +0300 (Чт, 17 дек 2009) | 2 lines
* [engine update] Вернул отображение причины автобана в панели активных скачек
* Попытка исправления неверно отображаемого текста в колонке "Расположение" панели активных скачек
------------------------------------------------------------------------
r3339 | rain.bipper | 2009-12-16 21:03:18 +0300 (Ср, 16 дек 2009) | 1 line
* Обновление скрипта-генератора файла PortalBrowser.xml
------------------------------------------------------------------------
r3338 | rain.bipper | 2009-12-16 20:35:03 +0300 (Ср, 16 дек 2009) | 1 line
* Исправлено отображениях иконок customlocations в панели активных скачек, при большом количестве элементов в списке локейшенов (> 128)
Сообщения
16 комментариев:
С CustomLocations все стало вроде как нормально, а вот DHT функциклирует как-то очень формально - и обмен маловат резко по DHT, и результатов не видно (по dht.xml и логам)
Хинт - в Стронге DHT пашет по полной без проблем
Скажу банальную вещь относительно UPNP.
Похоже все DC++ клиенты используют одинаковые алгоритмы работы с UPNP-устройствами, причем видимо поддерживается только то, что называется протоколом IGD (Internet Gateway Device). По умолчанию по крайней мере у меня Windows XP оказалась совершенно не сконфигурирована для этого. Нагуглил довольно древнюю инструкцию, согласно которой мне удалось настроить систему для того, чтобы UPNP завелся в стронге и соответственно флайлинке. Вот она: ссылка
Лично у меня в системе был выключен автоматический запуск "Universal Plug and Play Device Host" и был отключен "UPnP User Interface" (см. подробнее по ссылке выше). Из-за этого никакой UPNP в DC-клиентах не работал. После пинка в запуск службы UPNP и включения UPNP-юзвер-интерфейса - UPNP-функциональность стала работать.
И при всем при этом алгоритмы UPNP, используемые в торрент-клиентах, базируются на чем-то другом и вообще не требуют от пользователя возни с подключением IGD...
Собственно, как мне кажется, проблема может быть даже только в отключенном по умолчанию "UPnP User Interface", т.к. именно его включение сопровождается сообщением о том, что, мол, если вы его включите - то только тогда Windows Firewall соизволит открыть нужные порты для работы с UPNP-устройствами (роутером).
А вот реализация UPNP в торрент-клиентах видимо работает без участия Windows Firewall'а.
Приношу извинения, если это уже обсуждалось в блоге ранее, просто для меня подобные вещи стали открытием. Может быть, кому-то еще поможет.
Продолжив поиск по сети, удалось выудить следующую ссылку на багтрекер ApexDC++: в ней предложен патч для ApexDC++, реализующий UPNP с помощью отдельной либы MiniUPnPc, которая, судя по всему, много менее зависима от настроек Windows в отличие от текущего netupnp.h, а то еще и будет работать в Linux.
Предлагаю попробовать воспользоваться этими наработками. Я, к сожалению, не настолько хорошо умею программировать, чтобы адаптировать данный патч для флайлинка. Все надежды на тов. brain-ripper. :)
Продолжив поиск по сети, удалось выудить следующую ссылку на багтрекер ApexDC++: в ней предложен патч для ApexDC++, реализующий UPNP с помощью отдельной либы MiniUPnPc, которая, судя по всему, много менее зависима от настроек Windows в отличие от текущего netupnp.h, а то еще и будет работать в Linux.
Спасибо за старания.
Эту либу я уже пробовал - она не нашла моего роутера, в отличие от того же виндового сервиса.
Лично я склоняюсь все-таки к использованию последнего, т.к. золотое правило программирования - не надо изобретать велосипедов.
Если вся глючность использования UPnP заключается в неумении его настроить в системе - то это глюк пользователя :) Тогда основной проблемой будет идентифицировать проблему и выдать что-то типа "Включите сервис UPnP там-то и там-то", а еще лучше запустить его автоматом с благословления пользователя.
В последнее время что-то перестал у меня не получается заглючить Флаевский UPnP, нормально пробрасывает порты, поэтому отладкой не занимаюсь.
В прошлой ветке кто-то предложил упростить интерфейс настройки соединения в клиенте до уровня торрента, если удастся поправить упнп. Помоему неплохая идея.., даже если упнп запустить не удастся, моё предложение(просьба) сделать это в следующем релизе флая :)
И ещё, проперка портов: http://www.flylinkdc.ru/test.php?port_IP=44&port_PI=45&ver=3078 не работает, выводится вот такое:
Кодинг: SkazochNik (skazochnik97@mail.ru)
Мысли: PPA (ppa@lipetsk.ru)
Версия от: 26.08.2009
В следующем релизе будет только обновление ядра и косметика.
А вообще идея не плохая, согласен.
Кстати режим автоопределения активного/пассивного режима уже давно есть во Флае и, насколько я знаю аналочиной фичи нет у остальных клиентов.
Эту либу я уже пробовал - она не нашла моего роутера, в отличие от того же виндового сервиса.
Однако эта либа без проблем нашла мой роутер (Dlink) при отключенном виндовом UPnP User Interface'е.
При этом она вроде как продолжает разрабатываться, а приведенная реализация в ApexDC позволяет без особых проблем ее обновлять.
Кроме того, если принять комментарии к приведенному выше патчу ApexDC за истинные - там будет исходно использоваться данная либа, а в случае ее неудачи - виндовый сервис.
Если вся глючность использования UPnP заключается в неумении его настроить в системе - то это глюк пользователя
Я думаю, что всем известно, насколько сложно заставить большинство пользователей проводить какие-то внутренние настройки системы (боже мой, включать выключенные по умолчанию системные службы, запускать ифейс UPNP - да ни в жизни основная масса народа туда не полезет). При включении во флайлинк данного патча никуда лезть и не потребуется. В тех же торрент-клиентах никуда лезть не надо для UPNP.
Плюс опять же кроссплатформенность - текущая реализация работает ведь только под Windows?
В последнее время что-то перестал у меня не получается заглючить Флаевский UPnP
Так вы UPnP User Interface выключите - все сразу и сломается...
Подскажите, как нынче исключить из шары определённые файлы. Раньше прописывал в Настройки-Шара-Не добавлять в шару файлы со звёздочками, а теперь как ни прописываю, всё-равно ВСЕ файлы шарятся.
Кстати режим автоопределения активного/пассивного режима уже давно есть во Флае и, насколько я знаю аналочиной фичи нет у остальных клиентов.
Ну вот, тем более не нужно пугать пользователей грузным интерфейсом.
Опции ручного выбора пассивного/активного режима нужны разве что только разработчикам, которые могут обойтись любым другим клиентом.
Пускай флайлинк всё автоматически определяет и устанавливает, есть много других вещей, которыми можно загрузить мозг нуба.
Вот две строки из лога, есть ли какие-либо комментарии по этому поводу (исключительно о скорости, и только)
2009-12-19 11:46: C:\TEMP\Кромов.avi downloaded from Webber (VZM2PETRJRK2WJUGKV6RHK5BJCF2KGJEIZYKSKQ), 4194304 (4194304), 1.13 MiB/s, 0:00:03
2009-12-19 11:50: C:\TEMP\Кромов.avi downloaded from LazyBadger (OZ5GHV7NNHEAVBO7JQV5XL6KTUB2LGD5AOUXHXQ), 83529956 (83529956), 12.11 MiB/s, 0:00:06
Тест получился случайно, но считаю,вполне честным
- в тесте принимала участие одна и та же пара хостов
- передача шла по максимально пустой и идентичной по условиям сетке
- приемник один и тот же: RSX++ 1.11
Webber - это 20 альфа флая, ADCS коннект
LazyBadger - это "другой клиент" (чтобы не вызывать нездоровых истерик назовем так), ADC коннект
Вот две строки из лога, есть ли какие-либо комментарии по этому поводу (исключительно о скорости, и только)
Для комментариев нет никакой информациии. Ни достаточной статистики, ни сравнения настроек клиентов. Ну и фактических данных не хватает: например, судя по логу, Флай отдал файл на скорости 1.13 MiB/s за 3 секунды, а "другой клиент" тот же файл, на скорости 12.11 MiB/s, отдал за 6 секунд.
судя по логу, Флай отдал 4 мегабайта на скорости 1.13 MiB/s за 3 секунды, а "другой клиент" (greylink) 83 мегабайта, на скорости 12.11 MiB/s, отдал за 6 секунд.
Да, точно.
Но это не меняет сути моего комментария
вообще-то уже были жалобы на медленную отдачу файл-листов, так что проверять в любом случае буду.
Кое-что исправлял по этому поводу, но не тестировал еще
Отправить комментарий