Если у вас возникают проблемы с закачкой или поиском файлов (вроде, всё делаете как надо, а ничего не качается или поиск выдаёт пустой список), уясните себе, что хаб DC (сервер) тут совершенно не при чем. Передача файлов происходит напрямую от клиента к клиенту, поэтому помехи могут быть только на пути между клиентами.
Симптомы обычно такие: вы ставите файл (или список файлов) на закачку, ждёте, ждёте, ... а ничего не происходит, а потом DC пишет про "таймаут соединения":
Помните, что правильная настройка самого DC-клиента ещё не означает правильной настройки системы, сети и других приложений, которые могут влиять на DC++.
Вариантов проблем тут по сути всего три (первый - наиболее частый):
- Неправильно настроен межсетевой экран (файерволл, брэндмауэр, антивирус или любое другое средство сетевой защиты) у вас или у другого пользователя, и он просто блокирует сетевое соединение. в этом случае внимательно читайте данную страницу.
- Неправильно настроен DC-клиент у вас (или у того, у кого вы качаете файлы). Возможны случаи, когда вы при неверных настройках системы, сетевых экранов и т.д. вы можете что-то скачать у другого юзера, а он у вас - нет. Рекомендуем ещё раз ознакомиться с разделом настройки DC-клиента . Если не качается вообще ни у кого, значит скорее всего проблема именно у вас, а не у других.
- Соединение по локальной сети между двумя данными пользователями (или сегментами сети) заблокировано провайдером. В этом случае повлиять на ситуацию Вы не можете, просто считайте что данный юзер вам недоступен и воспринимайте это как данное свыше.
Правильные сетевые настройки DC-клиента
Если у вас не прямое подключение компьютера к сети, а через роутер (маршрутизатор), то настройки могут отличаться. А если у вас провод от провайдера втыкается прямо в комп, то проверьте, что у вас включен активный режим передачи файлов (Файл - Настройки - Настройки соединения ):
Остальные настройки DC++ на сетевые соединения никак не влияют. Так что если у вас тут всё выбрано как на картинке, значит проблема наверняка не в настройка клиента (то есть, читайте дальше).
Межсетевые экраны, антивирусы и их влияние на работу DC++
Ниже перечислено то, что может отрицательно влиять на работу DC++.
- Программные firewall-ы (фаерволлы, брендмауэры, межсетевые экраны) - программы для защиты от атак из сети.
- Брендмауэр Windows.
- Анти-вирусы, анти-руткиты и прочие аналогичные программы
- Аппаратные firewall-ы - "железная" сетевая защита, встроенная в сетевые платы и т.д.
Если вы не знаете, что это такое, ниже приведен перечень популярных программ такого типа:
Антивирусы
: Касперский (Антивирус, АнтиХакер, Internet Security), Eset NOD32, Symantec (Norton AntiVirus, Internet Security),
Trend PC-Cillin, Avira Avast, DrWeb, McAfee Antivirus, Panda.
Firewall-ы
: Outpost, WinGate, UserGate, WinProxy, WinRoute, ZoneAlarm, Comodo.
Что же касается аппаратных firewall-ов, пока нам известен только nVidia firewall
, встроенный в
материнские платы на чипсетах nVidia N-Force
. Как его отключить читайте руководство по материнской плате.
Как быть, если у вас есть перечисленные программы или им аналогичные? Для начала вы можете попробовать полностью их отключить или настроить так, чтобы они не блокировали сетевые соединения (либо совсем все, либо те, которые создаются приложением DC++. Даже если вы боитесь отключать защиту - вы можете сделать это временно и проверить, что причина того, что DC++ не работает, была именно в данной программе. Причем подойдите к вопросу творчески, поэкспериментируйте с настройками вашего фаерволла или антивируса и добейтесь того, чтобы он не блокировал DC.
К сожалению, опыт говорит о том, что такие антивирусы, как NOD32 и Norton (Symantec) Internet Security обладают следующим неприятным свойством: даже полное их отключение (а в некоторых случаях - деинсталляция) на самом деле полным не является и всё равно создаёт помехи в работе DC++. Способов борьбы с этим (кроме самых радикальных вроде переустановки чистой системы) нам пока неизвестно. Причины кроются в некорректной работе этих программ и/или их деинсталляторов, повлиять на которые у пользователя возможности нет.
Для подключения к хабу в DC++ обычно используется 411 TCP-порт (зависит от настроек самого хаба, но на большинстве хабов он именно такой). В активном режиме DC++ использует многие порты для соединений с юзерами; в режиме ручного перенаправления - только тот порт, который указан в настройках.
Если НИЧЕГО из перечисленного не помогает:
Остаются только радикальные меры: переустановить "чистую" винду без лишних программ защиты. Многим пользователям оно кстати совершенно не повредит. Поверьте, потратить даже три часа на полную переустановкиу системы - это быстрее, чем три дня искать причину неработоспособности чёрт знает в какой программе. При том не советуе пользоваться "самосборками" Windows - они тоже бывают весьма "кривые", и гарантировать бесперебойную работу DC на этих системах вам никто не будет (благо опять-таки, есть печальный опыт наступания пользователей на эти грабли).
Разумеется, те же самые 2 порта (2000 TCP и 2000 UDP) должны быть разрешены на вход/выход в настройках фаерволла.
Подробное описание многих файрволлов (немного старое, но не потерявшее актуальности) и их настройки есть .
Настройка брэндмауэра Windows
Встроенная сетевая защита ОС Windows XP SP2, Windows 2003, Windows Vista настраивается достаточно просто - достаточно добавить FlyLinkDC.exe в список исключений брендмауэра. Обычно при первом запуске DC++ система спросит вас, разрешать или не разрешать соединения:
В Vista сообщение выглядит иначе:
Нажимаете кнопку Unblock (Разрешить ). Тем самым вы добавите DC++ в список исключений. Если вы этого не сделали при первом запуске, можете сделать это в лббой момент: зайдите в Панель управления/Control Panel, Центр обеспечения безопасности/Windows Security Center, Брэндмауэр/Windows Firewall - и там на вкладке "Исключения" добавьте FlyLinkDC.exe . Вот соответствующие картинки: (нажмите на них для увеличения):
После этого всё должно работать.
Ошибка MySQL Server Has Gone Away (error 2006) может возникнуть в двух случаях.
Таймаут соединения
Наиболее распространенная проблема: таймаут соединения, в результате чего сервер его закрывает. Решение весьма тривиальное — увеличение лимита времени wait_timeout в файле конфигурации my.cnf . Для этого в Debian нужно выполнить:
Sudo nano /etc/mysql/my.cnf
# Открытие файла настроек MySQL
Затем установить тайм-аут ожидания:
Wait_timeout = 600
# Время ожидания в секундах, можно установить вплоть до 28800 с (8 часов)
Не забудьте перезагрузить базу:
Sudo /etc/init.d/mysql restart
Иногда, при выполнении длительных запланированных задач, также может появиться ошибка MySQL Server Has Gone Away все из-за того же таймаута соединения. При этом лимит времени не получится существенно увеличить (максимум до нескольких часов), так как это может привести к заполнению буфера ожидающими соединениями.
Поэтому лучше проверить соединение и, при необходимости, переподключиться.
$link = mysql_connect ("localhost","root","root"); # Здесь будут cron jobs if(!mysql_ping ($link)) $link = mysql_connect ("localhost","root","root", true);
# Подключение БД и переподключение при необходимости
Большой или некорректный пакет
Вторая распространенная проблема: сервер получает большой или некорректный пакет и отклоняет его. В этом случае сервер считает, что проблема на стороне клиента и закрывает соединение. Так что для решения нужно увеличить лимит на максимальный размер пакета все в том же файле конфигурации:
... max_allowed_packet = 64M …
# Увеличение лимита размера входящего пакета, в МБ
Также не забудьте перезагрузить базу данных.
Самое главное
После того, как устраните ошибку MySQL Server Has Gone Away, поиграйтесь с параметрами wait_timeout и max_allowed_packet для получения оптимальных лимитов.
Если передача небольших файлов происходит без проблем, но загрузка больших файлов обрывается по таймауту, причиной этого является неправильно настроенный роутер и/или файрвол находящийся между клиентом и сервером.
Как было сказано выше, в FTP используются два TCP-подключения: контрольное подключение для отсылки команд и получения ответов на команды, а также подключение для передачи данных. По принципу работы FTP контрольное соединение не используется во время передачи файлов.
В спецификации TCP не указывается лимит времени для сохранения неиспользуемого подключения. Предполагается, что подключение сохраняется на неопределенное время пока не будет закрыто явным образом. Тем не менее, большинство роутеров и файрволов автоматически закрывают свободные подключения по истечению некоторого времени. Более того, в большинстве случаев разрыв соединения происходит без уведомления об этом его участников. В случае продолжительной передачи данных через FTP , это значит, что контрольное соединение может быть разорвано, но ни клиент, ни сервер не будут об этом уведомлены. Таким образом, после того, как все данные были переданы, сервер все еще ожидает, что контрольное подключение можно использовать и отсылает через него подтверждение передачи клиенту. Аналогично, клиент готов использовать контрольное соединение и ожидает ответа от сервера. Но, т.к. контрольное соединение было разорвано, это ответ никогда не будет доставлен, что приводит к таймауту.
Для решения этой проблемы спецификация TCP предусматривает способ отправки пакетов для поддержки неиспользуемого подключения, сообщающих участников о том, что соединение требуется сохранить для дальнейшего использования. Тем не менее, в спецификации TCP явно указывается, что такие пакеты можно передавать не чаще, чем один раз каждые два часа. Для этого, предусматривая задержки в сети, срок жизни неиспользуемого подключения устанавливается спецификацией в 2 часа и 4 минуты.
Препятствием этому служит то, что многие роутеры и файрволы разрывают соединения, которые не использовались меньше чем 2 и 4 минуты. Такое поведение нарушает спецификацию протокола TCP, в RFC 5382 это указано достаточно ясно. Другими словами, роутеры и файрволы, разрывающие соединение раньше нужного момента, нельзя признать рабочими, т.к. они не могут использоваться при длительной передаче данных через FTP. К сожалению, производители роутеров потребительского класса и поставщики файрволов не заботятся о соблюдении спецификаций.
Для решения этой проблемы вам нужно удалить такие файрволы и заменить неправильно работающий роутер на качественный.
Во-первых, при переходе с Indy на Synapse у разработчиков часто возникают вопросы именно в части того, как Synapse использует различные таймауты, а именно — как установить таймаут на соединение, чтение/запись данных, почему не срабатывает таймаут и т.д. Достаточно забить в поиск фразу «таймаут synapse» и посмотреть различные обсуждения на форумах.
Во-вторых, т.к. библиотека Synapse постоянно развивается и дорабатывается, то может возникнуть ситуация, когда какое-либо свойство объекта Synapse отсутствует в исходниках разработчика, но имеется в той версии библиотеки, которую используем мы, когда пишем о Synapse.
Так как специально вопрос использования тайм-аутов в Synapse мы в главе по сокетам не рассматривали, то, думаю, что этот пост станет небольшим примечанием (или несколькими примечаниями) в книге и поможет избавить разработчиков от некоторых вопросов по использованию Synapse.
Версия Synapse и версии модулей Synapse
На момент написания этой статьи самой актуальной стабильной версией Synapse была Synapse release no. 40 . Актуальная версия библиотеки выкладывается на этой странице официального сайта в виде обычного zip-архива, содержащего все модули библиотеки.
Итак, с версией библиотеки разобрались — это двухзначное число (пока двухзначное), которое можно увидеть на странице загрузок
Помимо архива со стабильной версией нам также предоставляется возможность получать самые свежие исходники Synapse из репозитория на SourceForge. О том, как скачивать исходники из SVN можно узнать из двух статей, опубликованных в блоге ранее.