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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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


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

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


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

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

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

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

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


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

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

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

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