TimeOUT

Интересует следующий вопрос,

Провел эксперимент, если у пользователя каким-то образом рвется соединение, например диал-ап или плохая линия, то хаб не пускает обратно около 15 минут ...

В настройках обнаружил следующие таймауты:


прочитал на вики что все величины заданы в секундах ... пробовал менять эту величину на 60,000000 (1 мин) хаб не реагирует..
еще зачем после запятой столько нулей ???

*** как проверял у себя захожу на хаб ...рву впн (отключаю) ..поднимаю впн ..на хаб не пускает ...))

Что значит не пускает? Что пишет?

Это таймауты стадий входа. В течение этого времени клиент должен отослать соответствующую команду стадии входа. Если он не отсылает, то хаб принудительно закрывает соединение. Нули после запятой - это просто формат такой по умолчанию - 6 знаков после запятой

пишет содержимое этой строки из настройки:
<Item Name="sUsedNick">Этот ник %[nick] уже используется другим пользователем.</Item>
ну якобы этот ник все еще на хабе находится ...

есть какие мнения, Илья ?

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

dj_crazy_joker, рестарт компа тут не причем, но подмечено верно - смена ника решает проблему, видимо приходится ждать пока хаб не обновит список пользователей .... по моим подсчетам это занимает от 15 до 17 минут ..

ShadoWx
Ну мне лично всегда рестарт компа помогал

Данное сообщение показывается если выполнены следующие условия:
1). На хабе есть пользователь, который имеет данный ник.
2). У этого пользователя профиль не равен -1, то есть этот пользователь является зарегистрированным.
3). IP входящего пользователя и IP пользователя, который находится на хабе НЕ совпадают.

Современные DC клиенты пингуют хаб (примерно каждые 2 минуты). Возможно стоит сделать для таких клиентов проверку связи, то есть если клиент долго не пингует хаб, то отключать его. Хотя это не есть хорошо.

1). На хабе есть пользователь, который имеет данный ник.
Илья, если пользователь не зарегистрирован, то входящий с таки же ником займет его место, а того выкинет =) только что проверил

3). IP входящего пользователя и IP пользователя, который находится на хабе НЕ совпадают.
а вот и нашел я свою проблему =) .. у меня динамика и когда я искусственно рвал соединение и поднимал - ip менялся... но я одно не пойму ..почему надо ждать до17 минут где-то ...

На какой ОС стоит хаб?

ShadoWx
Попробуй с локального зайти или у тя хаб не в локалки?

Setuper, Debian.

И ....

Вернул настройку iTimeoutAny. По умолчанию 600 секунд (10 минут).
Хаб теперь проверяет, что клиент что-то отправлял в течении iTimeoutAny секунд, в противном случае дропает клиента.
Современные клиенты делают пинги хаба (отсылка пустой команды - команды, состоящей из одного символа | ). Если хаб часто сбрасывает пользователей, то нужно увеличить величину этой найстройки, однако, если хаб никого не сбрасывает, то эта настройка наоборот может быть уменьшена до интервала пинга со стороны клиентов, который обычно составляет порядка 2-3 минут.

Благодарю

По всей видимости всё же придётся убрать этот таймаут, ибо EiskaltDC не посылает на хаб пинги.

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

как я вижу ..может сделать что то вроде обновления списка пользователей ... с каким-нибудь интервалом ...

Если от клиента не поступает никаких команд, то о клиенте фактически ничего не известно, и не понятно жив ли он.
Вообще говоря механизм пингов обеих сторон взаимодействия (хаба и клиента) должен быть заложен в протоколе взаимодействия (в частности в протоколе NMDC). Однако, многие клиенты не пингуют хаб. Поэтому хабу очень сложно понять жив ли клиент.

Конечно можно это всё на уровне TCP протокола организовывать, однако механизм на различных ОС может сильно различаться.

В общем я буду думать и пробовать это как-то реализовать.
По всей видимости такие проблемы возникают только при динамических ip.

Главное багу сообщил, спасибо за ответ