Версия для печати темы

Автор: Meloun 4.1.2012, 20:40

В догонку к найденной инфе от авторов СтронгДЦ (http://mydc.ru/index.html?showtopic=5095&view=findpost&p=41611) где они весьма элегантно заюзали технологию NAT Traversal (файлообмен между двумя юзерами за NAT) в обход хаба, мгновенно родилась идея встроить это в функционал самого хаба.

Написав в переводе документации о том, что поддержка от хаба не нужна я немного слукавил. Дело в том, что я сам являюсь автором одного движка хаба и когда писал алгоритм парсинга CTM команды сделал это несколько сурово, строго по спецификации протокола. И когда в логах начали попадаться сообщения о "неправильном" формате CTM начал ковырять источник причины. Всё уперлось в СтронгДЦ, сначало это были приписки символа S к номеру порту, тогда я интуитивно сообразил, что это инициализация TLS, но когда CTM команды стали мало того, что с приписками разных символов к порту, так еще и с добавлением имени пользователя в озадачился всерьез. Собственно инфу о причинах нарыл, реально был в восторге как элегантно и просто была решена проблема фалообмена между двумя пассивами (отчего раньше никто не додумался)) ).

В общем перехожу к делу. А что если сделать такую фишку средствами хаба для всех клиентов даже для самых древних. Опишу вербальный алгоритм.

Клиенты коннектятся к хабу, передают MyINFO где указан режим. Если режим пассивный, то рассылаем всем правленный MyINFO как будто клиент активный, но естественно хаб будет знать кто в активе, а кто в пассиве. Можно также добавить проверку активных пользователей на предмет открытия TCP порта для активного режима, в случае его закрытости хаб будет считать клиента пассивным (это я уже реализовал, прекрасно работает, кому интересно могу описать алгоритм).

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

Если CTM или RevConnectToMe приходит от пассива и адресована пассиву, тогда отправляем команду CTM и первому и второму клиенту, только порты указываем локальные с которых подключены к хабу по аналогии как расписывал в документации (см. ссылку в самом начале поста расширение NAT Traversal) только никаких N и R добавлять к порту не надо.

Вот интересно старые клиенты такой финт с организацией "туннеля" через НАТы "схавают" или все же программеры стронга там что-то особенное с сокетами намудрили?

Жду собеседников для конструктивного обсуждения...

Автор: mariner 4.1.2012, 21:25

Скорее всего при "пробивании" нат используется UDP протокол, так что старые клиенты как не могли, так и не смогут

Автор: Meloun 4.1.2012, 21:40

Несогласен. Используется не UDP протокол а TCP, т.к. NATы "пробиваются" по локальным TCP портам с которых пользователи приконнектились к хабу.

Вот нашел интересные ссылочки по теме:
http://mydc.ru/r/?http://mdt.kz/viewtopic.php?f=4&t=33
http://mydc.ru/r/?http://dcpp.wordpress.com/2010/02/13/passive-mode-c-c-connections-and-nat-traversal/

Автор: mariner 4.1.2012, 21:56

Вам не кажется. что это создаст определенную нагрузку на хаб? А еще получается уже не П2П

Автор: Setuper 4.1.2012, 22:01

Как-то пытался что-то подобное изобрести ( http://mydc.ru/topic4725.html ), однако пока отказался от этой идеи.

Автор: Meloun 4.1.2012, 22:23

Не шибко сильную нагрузку создаст, если не проверять у активных клиентов порты, то весь оверхед будет состоять из изменения режима в MyINFO и отправки правленных команд CTM двум пользователям. Как это не P2P? Еще как П2П, непосредственно файлообмен будет идти без участия хаба, путём создания TCP сессии между двумя стейтами в НАТах.
Вот еще интересные ссылочки:
http://mydc.ru/r/?http://mdt.kz/viewtopic.php?f=4&t=32
http://mydc.ru/r/?http://www.brynosaurus.com/pub/net/p2pnat/
У этой реализации как видно есть некоторые ограничения ((


В том-то и дело, что насколько понял программеры StrongDC вообще без UDP обошлись, дырявят наты через TCP-сессии. Решение мегапростое, настолько простое, что можно попробовать реализовать самим хабом. Весь вопрос только в том как именно реализован алгоритм инициализации TCP соединений в новом стронге для использования дырок.

Автор: Setuper 4.1.2012, 22:40

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

Автор: Meloun 4.1.2012, 23:04

Попробую реализовать эту фишку у себя. По результатам отпишусь и возможно попрошу содействия в тестировании.

Пока не нашел инфу о такой фичи для помощи тем у кого постоянно меняется IP и клиент глючит, нехочет брать IP из команды $UserIP2, реализовал у себя такую хрень, поисковые запросы и CTM с IP отличающимися от того с которого коннектится пользователь патчатся, IP меняется на тот с которого зашел пользователь, алгоритм отлажен и оптимизирован, работает шустро.
Для тех кто тупит конкретно и не может не только настроить активный режим через НАТ или брандмауэр, но и переключиться в пассив делаю так:
Клиент коннектится к хабу, если он в активе, то ему отсылается команда RCM с именем бота, правильный клиент присылает в ответ CTM (на этом этапе легко отсеиваются часть спам-роботов) оттуда определяем активный порт, сканируем его, если открыт, то ок, закрыт, то принудительно перекл.ючаем в пассив, т.е. патчим MyINFO дабы другие видели что на самом деле пассив, также команды на активный поиск от этого клиента преобразуем в пассивные, CTM преобразуем в RCM. Всё работает на УРА! Все рады...

Всё это встроено в сам движок хаба, особого увеличения нагрузки не вижу. Можете потестировать dc.sungate.su

Если выгорит с "продырявливанием" НАТов, вообще будет супер. ДЦ станет доступным даже для самых блондинок %) Конкуренция с торрентами будет существеннее.

Автор: mariner 4.1.2012, 23:14

я вот давно хочу предложить не насиловать труп, а перейти на адц. Как русхаб будет иметь АДЦ, то я, возможно, перейду на него.

Автор: Meloun 4.1.2012, 23:23

Ребята которые пилят ФлэксХаб также пилят модификацию ADC обратносовместимого с NMDC. Незнаю, что у них получится, но с интересом слежу.

А вообще ADC какой-то замороченный, NMDC при достаточной простоте еще весьма живуч и востребован, с появлением DHT стал еще более привлекательным, вот народ и начал расширения новые под него пилить.

Долго курил документацию по ADC, некоторых моментов нихрена не понял, некоторые моменты еще более геморойнее чем в NMDC. В итоге взял и спокойно напилил хаб под NMDC и сейчас спокойно расширяю его функционал штатными методами, доволен.

Не спешите хоронить старичка

Автор: mariner 4.1.2012, 23:46

Пора бы уже и закопать. Банально - если обвесить NMDC всеми этими расширениями то получим ADC.

Но в АДС это предусмотрено из коробки, а тут 100500 расширений, которые не все клиенты тянут. Ну и наконец, в ADC, на сколько я помню, служебные слова покороче. Пустячок, а нагрузку на сеть слегка срежет.

Если уж совсем "по трушному" делать, то еще и сразу SCTP использовать, вместо унылого TCP.

А на счет ФлексХаба - не смотри ты на них. Это забавный проект, но в конечном счете не нужный, ибо "too slow".

Автор: Setuper 4.1.2012, 23:48

Я смотрел код флекс хаба и уже критично говорил по поводу автоопределения протокола. Автоопределение во флексе осуществляется следующим образом: всё основывается на том, кто первым начинает отправлять команды. По протоколу NMDC клиент коннектится к хабу и ждёт от него команд, по ADC протоколу - клиент коннектится к хабу и сразу отсылает первые команды, то есть поведение в принципе другое. Но на этом нельзя основываться.

Флекс хаб делает так: к нему коннектится клиент, после аксепта клиента хаб некоторое время ждёт от него команд, если команды пришли, то протокол ADC, иначе протокол NMDC. Возникает логичный вопрос: как долго хабу ждать этих команд? По коду флекс хаб ждёт, ровно столько, сколько на хабе выполняются действия от accept до recv, а так как флекс хаб написан на lua, то быстрым его никак нельзя считать, поэтому ADC клиент успевает отослать нужные команды прежде, чем хаб выполнит действия от accept до recv. Поэтому с первого взгляда всё хорошо. Но даже если бы на хабе была некоторая задержка для получения команд, то всё равно вопрос остаётся открытым: какая должна быть эта задержка? А если сеть перегружена и пакеты доставляются очень медленно, - получается в таком случае ADC клиент будет признан NMDC клиентом.

В общем так делать нельзя. И это не пустые размышления. Я проверял данный факт на моём русхабе, который работает быстрее клиента, который коннектится, и по такой схеме получалось так, что ADC клиент признавался NMDC клиентом.

Конечно можно совместить на одно хабе 2 протокола, но за каждым протоколом должен быть однозначно закреплён свой порт! То есть чтобы номер порта однозначно определял протокол.

Автор: Meloun 4.1.2012, 23:54

Главная проблема ADC это отсутствие обратной совместимости с NMDC ИМХО. Вот и вся причина холиваров на эту тему. А ребята заморачивающиеся с ФлэксХабом молодцы. DirectConnect уже давно альтруистский проект никем не финансируемый в отличии от Torrent и благодаря таким вот самоделкиным развивается.

Вообще моё конечное мнение: ADC не решает всех проблем NMDC, закрыли одни дыры добавили другие. Ждёмс ADCv2...))

Автор: mariner 4.1.2012, 23:55

Я так понимаю ты своё авторитетное мнение не обоснуешь?

Автор: Meloun 5.1.2012, 0:00

Обосную сразу первым что вспомнилось после изучения RTFM: лички в обход хаба - ахриненный стимулятор для спаммеров особенное сли всё-таки случится страшное и все начнкт массово переползать на ADC

Ну и вот еще, подделка CID со всеми вытекающими особенно для блондинок, которые толком вкурить не могут как пассив поставить, а поменять "украденый" CID и подавно.

Что-то еще было, но сейчас уже не помню...

Автор: mariner 5.1.2012, 0:05

А - решаемо
Б - и сейчас вроде есть. При использовании шифрования
В - права человека глянь еще. Право личной переписки.


Блондинко-проблемы. Это как пасскей в торренте. И ведь вроде никто не жалуется на пасскей.

Автор: Meloun 5.1.2012, 0:20

Setuper, касаемо такого метода определения протокола согласен несколько коряво. Также размышлял о объединении хабов NMDC и ADC на одном порту, так и не придумал ничего как действительно по разным портам раскидать. Но вот объединить файлообмен между пользователями ADC и NMDC в рамках одного хаба мне показалось на тот момент нереальным. Очень жду результатов от разработчиков Флэкса.

А - как? пароль на личку средствами клиента это вариант, но не для блондинок поэтому не рассматриваю как панацею
Б - только у грэйлинка если память не изменяет, соотв. есть вероятность спама в обход скриптов хаба.
В - хех вот уж не знаю, что лучше куча открытых окон со спамом в личках или "право личной переписки". общаясь в аське почему-то никто такими вопросами не задаётся))

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

Не убедил

Автор: mariner 5.1.2012, 0:23

Очевино, капча


Тогда какая проблема с CID?

Автор: Meloun 5.1.2012, 0:33

Угу если ента "капча" по умолчанию включена в клиенте, что-то таковых у которых "из коробки" стоит нужная галка пока не видел. Кроме того капчу подобрать не сложно, тут еще антиспам фильтр нужен потому как владельцу какого-нибудь мелкого хаба будет совсем не влом вбивая капчи рекламить на крупном хабе. Проходили уже такое.

Ну дык если под твоим CID сидит кто-нибудь другой ты не войдешь на ADC хаб, вот она и проблема по сути еще и уязвимость.

Автор: mariner 5.1.2012, 0:40

Я читал старую версию протокола. Там вроде при установлении соединения "лички" была команда. То есть я мог видеть, что они начали болтать. Ну и запретить хабом до ввода капчи слать эту команду.

А вот этого не знал. Думал, лишь что CID отсылается хабу в командах. Тогда бы проблем, в принципе, не было.

Автор: Meloun 5.1.2012, 1:27

Честно не помню коннект на личку отдельно передаётся или просто конект неважно для чего (скачивание файла или личка). Даже если на личку коннект отдельно передается, мы можем поставить только капчу, спам-фильтр прикурутить уже не удастся.

В общем у ADC свои неприятные тараканы имеются. Моё мнение после изучение документации ADC это, то что он как-то прям больше подходит именно для клиент-клиент взаимодействия, соотв. самой первой АДЦ командой которую портировали в клиенты была ADCGET и ведь ничего не мешало работать в совместимом режиме. Крупный стратегический просчёт разработчиков бросить старый протокол и переползать на абсолютно новый такой же сырой ИМХО.

Автор: Ksan 5.1.2012, 4:35

Э, не надо нам таких фишек, чтоб могли отправлять приваты помимо хаба, так вообще спамом забьют приваты..
Сейчас хоть как-то удаётся справляться с помощью скриптов..
И какому врагу человечества такое пришло в голову придумать и внедрить куда-то?

Автор: Meloun 5.1.2012, 6:24

Возвращаясь к исходной теме топика.

Поковырялся в реализации NAT Traversal для Стронга плюс вдумчиво почитал как это реализовано в ADC. Средствами хаба для старых клиентов это замутить неполучится, вся фишка в том, что для формирования "дырок" в NATах необходимо чтобы клиенты инициировали новое подключение с того же локального порта с которого они подключены к хабу. К сожалению старые клиенты выбирают этот порт рандомно всегда. Обломинго.

Однако! Средствами хаба можно помочь СтронгДЦ-клиентам в пассиве установить соединение между НАТами в случаях если НАТы не сохраняют соответствие между локальным портом клиента и портом открытым наружу. В этом случае клиент не знает номер внешнего порта, соответственно будет облом. На стороне хаба можно просто подменить в CTM командах порт на тот с которого клиент подключен к хабу. В результате еще больше повышаем вероятность установки коннекта между пассивными клиентами. Эта фича также справедлива и для ADC хабов.

Автор: Delia 5.1.2012, 8:34

в итоге делают херню. Причины озвучивались не раз, и их много. Например, глупейшая невозможность юзать русские ники. Блондинки в шоке.

И повод заставить кое-кого обновить клиент. Ибо иначе всё вышенадуманное работать один хрен не будет.

Касательно спереть CID. Всё хорошо, но каким хреном ты из него PID получишь?
Реальная история. Года два назад была мода(быстро утухла) - генерить себе осмысленную фразу в СИДе. Чувак хотел написать что-то вроде JUCYRULES. Обсчитал то ли первые два, то и первые четыре символа, а потом, говорит, всё, нужно комп месяцами гонять, чтоб ПИД рассчитать, а суперкомпьютера под рукой как-то нету.

Из описания INF команды.
Или я неправ?

Автор: Enyby 5.1.2012, 8:55

Я чего-то не пойму. Как собственно обходится двойной NAT? Хаб в роли ретранслятора?
Или же это на уповании, что NAT "сквозной"? Если так, то ничего может не работать в рамках сессии, отличных от той, для которой установлено соответствие в NAT.

UPD:
Почитал предлагаемые механизмы. Насколько понял, все это хорошо работает только с UDP инкапсуляцией. А с TCP это уже хак какой-то.

Автор: Meloun 5.1.2012, 9:28

Ну собственно про архитектуру ФлэксХаба ничего говорить не буду, т.к. не изучал, не ставил. Мне интересны предлагаемые ими расширения NMDC и модификация ADC для обратной совместимости с NMDC. Хабы которые будут обслуживатьодновременно подключения по обоим протоколам смогут быстрее перетащать пользователей на ADC, пользователь сидит там где больше пользователей, а на остальное ему пофиг, файлы -то один фиг качаются быстрее там где больше источников.

Касаемо PID-CID спорить не буду, спецификацию читал в 2008-м году, всё очень мутно там объяснялось. Единственные преимущества которые увидел это юникод и компактные команды, остальное хрень какая-то непонятная и хабу не шибко нужное, скорее только для взаимодействия между клиентами полезная. По поводу проблем с CID неоднократно читал на форумах как народ пытаясь без переустановки клиент копировать обламывался. Также порадовало обилие дыр и уязвимостей в этом ADC, есть несколько способов устроить неплохую ДДоС атаку с помощью этого протокола про спуфинг сообщений уж молчу. Вроде протокол развивается, но вот обновлённой документации нигде нет. Авторы клиентов в основном его вылизывают, но результаты трудов в виде описания изменений протокола трудно найти. С NMDC как-то проще всё, единственная засада которая рано или поздно наступит это массовый переход на IPv6, существенно местами придется перепиливать хабсофт и клиенты.




Хаб не ретранслятор, клиенты только используют номер локального порта сокета с которого коннектятся к хабу для "пробивания дырок" в обоих НАТах. Вариант с TCP это действительно хак, там даже есть бага когда сокеты переходят в состояние TIME_WAIT один из них может находиться в таком состоянии несколько минут, соотв. новые коннекты будут создаваться с задержкой.

Автор: mariner 5.1.2012, 10:51

в связи с переходом на айпивэ6 надо один раз переписать клиент и все. 6ые сокеты могут работать как 4ые. В чем вообще проблема?

а про вариант с тцп я уже выше писал. Не даром ведь скайп юзает удп. И вообще, давайте уж валить на сцтп

Автор: Delia 5.1.2012, 10:53

Да всё просто. Они просто отключили то, что с NMDC работать не может.

Извините, это бред собачий.

Пожалуйста, озвучь эти возможности. Просто про "дыры и уязвимости" я слышу давно, но нигде не видел даже теории проведения атак посредством ADC. Про CTM-атаку в новом протоколе когда-то вообще было сказано только что, мол, скорее всего, это нереально. И всё.

Вообще, забегая вперёд, скажу, что с ADC ситуация вообще более чем странная.

Разработчики протокола: Оно лучше NMDC! Оно развивается! У него большие перспективы!
Разработчики хабсофта: Мы знаем как это работает, но не знаем что с этим делать.
Разработчики DC клиентов: Да пусть будет, чё.
Юзвери: Чёза?!
Энтузиасты 1: И правда, большие перспективы. Надо, берём, ставим. Работает!
Энтузиасты 2: Ну, я поставил. Но почему passion отсутствует? Это что, одному мне надо?
Факты: Мы в домике!
Здравый смысл: Что-то где-то здесь не так.

Как-то так.
Можно плюсовать.

Автор: Meloun 5.1.2012, 11:32

+1 Собственно лаконичный и исчерпывающий ответ на все холивары вокруг ADC.

От себя добавлю. Документация протокола отвратительная, много белых пятен и нестыковок которые еще доконца не проработаны.

В любом случае надо его начинать осваивать. Нашел вот интересный форк хаба Dtella от студентов Кембриджа, впихнули туда поддержку ADC и TLS подключений Клиент-Хаб. Буду по нему разбираться в этом чуде инженерной мысли, попробую повелосипедить и скрестить по максимуму эти два протокола.

Ссылка: http://mydc.ru/r/?http://code.google.com/p/dtella-cambridge/



Ну тогда уж заодно и новая реализация ADCv2

Автор: arktik 11.1.2012, 9:48

Буду очень признателен, если поделишься секретом. Для моего хаба будет самое то =)

Автор: Meloun 11.1.2012, 21:07

Кодом поделиться несмогу т.к. этот функционал вшит в хаб, а хаб самописный. Опишу вербальный алгоритм.

Клиент подключается к хабу.

Если в тэге клиента стоит флаг активного режима, то от имени бота хаба (бот должен быть виден всем пользователям, т.е. хаб должен рассылать всем клиентам MyINFO с именем бота как если бы это был обычный пользователь) отсылается команда $ RevConnectToMe ИмяБота ИмяПользователя|

Если от клиента приходит $ConnectToMe ИмяБота IP:port| то сканируем на предмет открытия порта у клиента. Если открыт - активный режим настроен верно, если нет, то сообщаем клиенту что актив настроен не верно.


Я вообще сделал так , что если хаб определяет что у клиента неверно настроен активный режим, то средствами хаба меняются команды присылаемые клиентом пользователя. Поисковые запросы преобразуются в пассивные, $ConnectToMe превращается в $RevConnectToMe.

Грабли на которые можно наступить и которые следует предусмотреть:
-хаб должен игнорировать команды $ConnectToMe если оба клиента в пассивном режиме (в т.ч. и те пользователи у которых хаб определил неверно настроеный активный режим), иначе будет зацикливание (будут пинаться друг-другу запросы на подключения до бесконечности)
-всегда пропускать команду $ConnectToMe без изменений даже если она идет от пассива к пассиву, если она иммет формат NAT-Traversal (флаги N или R в номере порта) дабы дать возможность двум пассивам попробовать соединиться (см. расширение NAT-Traversal).
-хаб должен игнорировать команду $RevConnectToMe, если она от активного пользователя (в этом случае активными считаются и те у которых хаб определил что актив настроен неверно) и адресована пассивному (включая активных у кого хаб определил неверно настроенный актив), дабы также исключить возможность зацикливания.
- всегда пропускать команду $RevConnectToMe если она от пассивного клиента и адресована пассивному (в данном случае пассивными не будут считаться те, у кого хаб определил неверно настроеный активный режим) дабы дать возможность двум пассивам попробовать соединиться (см. NAT-Traversal)


Надеюсь более-менее понятно расписал.

Для наглядности, так сказать чтобы пощупать руками, включайте фаервол, указывайте в клиенте актив, открывайте окно CDM-отладчика в клиенте и коннектесь по адресу dc.sungate.su Лучше один раз увидеть...

Автор: arktik 12.1.2012, 4:03

А это обязательно? Разве клиенту не все равно, кто просит к нему подключится. Есть же скрипты для скрытого появления на хабе, что не мешает скачиванию.

Автор: Meloun 12.1.2012, 8:27

Крайне рекомендую. В Флайлинке, Грейлинке и м .б. в еще в других, реакция на запросы подключения будет если ник пользователя есть в списке юзверей иначе клиент просто проигнорирует эти команды от хаба. Установлено на личном опыте.

Автор: arktik 29.1.2012, 5:06

Не могу понять почему у меня ничего не работает. Определение порта, изменение типа поиска и СТМ проходит, но после соединения с пользователем, дальше команды Lock не идет.

P.S. У меня FlyLink r500, у удаленного Eiskaltdcpp-daemon. Обычным способом все работает.

Автор: Enyby 29.1.2012, 10:38

Надо смотреть код Eiskaltdcpp-daemon и искать реализацию там этой фичи. Возможно там параметр Ref называется как-то по другому. Или ожидается что-то еще, что не приходит.

Автор: arktik 29.1.2012, 12:36

Да, точно, проблема из-за eiskolt'a. Зря панику поднял значит

Автор: muznark 29.11.2023, 22:09

решение проблемы с клиентами с серыми ip адресами в локальных сетях:
1-если у меня серый адрес, то мне нужно быть в активном режиме для того, чтоб качать с соседей по локалке, и пользователи интернета в активном режиме могли с меня качать. и при этом быть в пассивном режиме, чтоб качать с пользователей интернета(только с тех, кто в активном режиме)
2-админы локальных хабов их закрывают, ссылаясь на наличие внешних хабов, а владельцы внешних хабов часто не лояльны к пользователям локалок с серыми адресами, чтоб исключить ситуацию наличие псегдоактивных пользователей(пользователь с серым адресом в активном режиме не может качать с пользователей интернета, пользователи интернета в пассивном режиме не могут качать с псегдоактивных пользователей)
3-решение проблемы: со стороны программы клиента-вход на хаб одновременно в активном(для локалки и внешних активных пользователей)и пассивном(чтоб качать с внешних активных пользователей)режиме.
со стороны внешнего хаба - лояльно относиться к двойным входам, допускать локальный адрес пользователя и не преобразовывать его во внешний адрес, если при конекте на внешний адрес и порт клиента порт закрыт.