Поддержка NAT Traversal хабом, Организация файлообмена между пассив. пользователями средствами хаба

В догонку к найденной инфе от авторов СтронгДЦ (NMDC Extensions) где они весьма элегантно заюзали технологию NAT Traversal (файлообмен между двумя юзерами за NAT) в обход хаба, мгновенно родилась идея встроить это в функционал самого хаба.

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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



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

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

Не убедил

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


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

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

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

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


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