Здесь показаны различия между двумя версиями данной страницы.
Both sides previous revision Предыдущая версия Следущая версия | Предыдущая версия Следущая версия Both sides next revision | ||
mini_faq [2009/07/01 11:36] злюки |
mini_faq [2010/06/11 00:57] admin старая ревизия восстановлена |
||
---|---|---|---|
Строка 2: | Строка 2: | ||
===== Содержание ===== | ===== Содержание ===== | ||
* **Основное** | * **Основное** | ||
- | * [[mini_faq:DC|"DC, с чем едят и чем закусывают"]] - основные понятия **Direct Connect** | + | * **[[mini_faq:DC|"DC, с чем едят и чем закусывают"]]** - основные понятия **Direct Connect** |
- | * [[modems_setup|"У, бесовcкая машина"]] - настройка ADSL модема, работующего в режиме роутера | + | * **[[modems_setup|"У, бесовcкая машина"]]** - настройка ADSL модема, работающего в режиме роутера |
- | * [[mini_faq:clientsetup|"А еще там чатик"]] - настройка клиента на примере **PeLinkDC** | + | * **[[mini_faq:clientsetup|"А еще там чатик"]]** - настройка клиента на примере **Apex DC++** |
- | * [[mini_faq:dcrules|"ДиСишная правда"]] - правила поведения в чате DC хаба | + | * **[[mini_faq:dcrules|"ДиСишная правда"]]** - правила поведения в чате DC хаба |
* **Дополнительно** | * **Дополнительно** | ||
- | * [[mini_faq:netoption|Параметры сети]] | + | * **[[mini_faq:netoption|Параметры сети]]** |
- | * [[mini_faq:dsp|DSP]] | + | * **[[mini_faq:dsp|DSP]]** |
| | ||
- | |||
- | ====== Direct Connect - принцип работы сети ====== | ||
- | |||
- | Основано на статье на сайте [[http://dccp.ru/node/412|dccp.ru]]. | ||
- | |||
- | Большая часть проблем новичков в DC++ подстерегает из-за банального непонимания происходящего. | ||
- | |||
- | Для решения большинства проблем с режимами работы и стандартными ошибками достаточно понимать основные принципы DC++, кои и постараюсь описать далее. | ||
- | |||
- | **Принцип работы:** | ||
- | |||
- | Клиенты А, B и С подключены к хабу. Клиент A захотел скачать файл N. | ||
- | На поисковый запрос клиенты B и C ответили что файл N находится в шаре у клиента B. | ||
- | Далее начинается самое интересное: | ||
- | |||
- | DC++ использует входящее соединение. Это значит, что клиент А просит клиента B: "хей! я хочу файл N. я открыл для тебя порт 30001. Мой адрес 192.168.1.5". | ||
- | Клиент B устанавливает соединение с клиентом A используя переданную информацию, после чего начинает передачу. Соединение устанавливается напрямую между клиентам минуя хаб. | ||
- | |||
- | Данный случай является идеальным, к несчастью в реальности нас могут подстерегать следующие проблемы: | ||
- | |||
- | У пользователя А установлен файрвол, который в автоматическом режиме считает все попытки установить соединение с компьютером атакой (даже встроенный в Windows файрвол делает это). Естественно игнорируя все попытки клиента B подключится. Это - типичная проблема серии: "У меня все качают а я не могу!". | ||
- | Решение - настроить файрвол корректно или отключить. | ||
- | |||
- | Пользователь А может находится за шлюзом NAT (Gateway). | ||
- | |||
- | В этом случае все соединения устанавливаемые клиентом А обрабатываются шлюзом, но соединится с ним снаружи - невозможно без использования технологии о которой скажу ниже. Если пользователь А установит в клиенте "Активный режим работы" - возникнет таже самая проблема: Отдача файлов возможна (тк соединится с В не проблема), а получение нет. | ||
- | Причина - при попытке установить соединение клиент В будет использовать внешний адрес шлюза. Аналогичная проблема возникнет при использовании Ethernet ADSL модема - он выступает в качестве шлюза, выдавая пользователю "внутренний IP адрес". | ||
- | |||
- | Какие IP адреса типично используются как внутренние? | ||
- | |||
- | 192.168.*.* , 10.*.*.* , 172.[16-31].*.* | ||
- | |||
- | В этом случае также возможна следующая проблема - внутренние хабы сети прекрасно работают, а внешние нет. (Соединения между клиентами внутри сети возможны, а снаружи подключится нельзя) | ||
- | |||
- | Клиент обычно вопит в этот момент: "время ожидания ответа истекло". | ||
- | |||
- | Что делать? | ||
- | |||
- | вариант 1 - самый распространенный: Пользователь переходит в пассивный режим: | ||
- | DC++ начинает использовать ТОЛЬКО исходящие соединения: | ||
- | |||
- | Компьютер А посылает компьютеру В запрос (через хаб): "Хей! я хочу файл N! Открой мне порт" - "На тебе порт 30001". Клиент А соединяется с Б используя эту информацию и начинает передачу. | ||
- | Результат - вы можете соединятся только с теми кто может принят ваш запрос. те с Активными клиентами. Связь пассив - пассив невозможна по этой же причине. | ||
- | |||
- | вариант 2 - настройка шлюза. | ||
- | Для преодоления подобный проблем была разработана технология перенаправления портов: | ||
- | |||
- | Шлюзу(модему) говорится примерно следующее: "все запросы на порт 30001 перенаправляй на клиента А". Как итог - Клиент В теперь может совершенно спокойно соединится с А. | ||
- | |||
- | В настройках клиента А выставляется принудительное использование порта и ip-адреса. (вместо локального ip там указывается внешний ip шлюза) | ||
- | |||
- | **Как работает поиск: ** | ||
- | |||
- | Если вы используете активный режим то поисковые запросы идут непосредственно пользователям. | ||
- | Если пассивный - поисковые запросы разруливает хаб. | ||
- | |||
- | Поиск и связь в активном режиме используют разные протоколы! для корректной работы, необходимо открыть для использования ОБА. | ||
- | |||
- | Когда поиск ничего не находит сначала, а через 10 минут находит то что искали, несмотря на то, что новые клиенты на хаб не заходили: | ||
- | Файл у юзера С. | ||
- | |||
- | Юзер А запуская поиск ищет чтото, посылая несколько запросов (+автопоиск альтернативных источников). Результат: Клиент С получает от А 6-9 запросов почти одновременно. после чего решает: "этот негодяй пытается использовать спам поиска!" бан на 2 минуты на все поисковые запросы." | ||