Что такое flood wait
Ошибки Телеграмм: параметры, основные категории, примеры
При работе с мессенджером пользователи иногда получают уведомления, свидетельствующие о возникновении определенной проблемы. Ошибки Телеграмм могут иметь разную природу и структуру, понимание которых, как правило, позволяет оперативно найти выход из сложившейся ситуации и продолжить работу с приложением.
Главные параметры ошибок
Служебное уведомление может включать следующие параметры:
Структура ошибок Телеграмм не предполагает обязательное использование всех трех параметров. Для разработчиков, работающих с API, уведомления зачастую включают код и тип ошибки, а для обычных клиентов – краткое описание, позволяющее даже неосведомленному человеку понять причину и найти выход из нестандартной ситуации.
Самые распространенные ошибки Телеграмм
Примеры внутренних ошибок мессенджера
Одним из наиболее распространенных явлений в мессенджере Telegram является запрет на отправку сообщений пользователям, не находящимся в списке контактов. При попытке отправить письмо появляется уведомление с текстом «Sorry, you can only send messages to mutual contacts at the moment» («К сожалению, сообщения вы можете отправлять только взаимным контактам»). Данное ограничение накладывается администрацией, если клиенты жалуются на навязчивость или спам со стороны какого-либо аккаунта.
Внутренние ошибки могут быть связаны с неправильной авторизацией или некорректным использованием функциональных возможностей приложения. Приведем несколько примеров:
Внутренняя ошибка Телеграмм — запрет на отправку сообщений
Наконец, разберем самые частые типы возникающих уведомлений:
Серверные ошибки Телеграмм
Внешние проблемы, связанные с работой сервера, возникают в результате технических неполадок, когда запрос от клиента не может быть обработан из-за отсутствия доступа к базе данных или конкретным файлам.
В этом случае пользователь получает одно из следующих уведомлений:
Внутренние неполадки сервера, как следствие недоступность мессенджера
Известные случаи падения Telegram
За период своего существования серьезные падения мессенджера Павла Дурова случались нечасто. По сути, их было всего три:
Самые крупные и известные случаи падения серверов Телеграмм
Problem sending massive msg. Error FLOOD_WAIT_86400 #407
Comments
kyroii commented Jan 23, 2015
Hi, I use tg-cli and I really think you’re doing dificult job developing tg-cli.
I have a problem and maybe you can help me. I’ve been using tg-cli to send massive telegram messages. Sometimes I send messages to all my contact list. There are not many, only about 100 contacts. I do this through a litle expect script which launch telegram cli, load contact_list and finally send the message. After every message there is a 3 seconds delay.
All was running perfectly until one day I got in my logs this error: FLOOD_WAIT_86400
I get that error when I try to send more than 60 msg’s consecutively. I mean, I can send the 60 firsts and then appears the error.
Far as I know this error appears when a user trys to send many msgs, but it worked fine before, so I suppose some rules has changed in telegram. When that happends I can’t send messages to the contacts I recived the error until 84600 seconds, or what is the same 1 day.
I’ve tested this with version Telegram-cli 0.01-beta and Telegram-cli 1.0.3.
With vesion 0.001 I get the error FLOOD_WAIT_86400.
With version 1.03 I just get the error Bad user/chat id, and of course, I can’t send messages to the contacts after a day, as well as with the other version.
The question is, How can I solve this problem?
Is there another way to do send messages to all my contact list without problems?
Thanks for your time.
The text was updated successfully, but these errors were encountered:
Протоколы состояния канала и однозоновый OSPF (часть 2)
Продолжение перевода главы из книги Chris Bryant «CCNP Route Study Guide». Его сайт — thebryantadvantage.com. Книга доступна на amazon.
Из всех просмотренных видео, прочитанных книг для подготовки к CCNP ROUTE, материал из этой показался наиболее легким для усвоения. Позволяет разложить все по полочкам. Кроме теории мне также понравились практические примеры. В конце каждой главы есть ссылки на уроки на youtube.
Часть 1.
Типы сетей OSPF
Почему типы сетей OSPF важны
По умолчанию тип сети OSPF зависит от типа сегмента сети. Различные типы сетей OSPF имеют различные значения hello- и dead- таймеров, и это одни из значений, которые должны совпадать для установления соседства между двумя маршрутизаторами. Кроме того, некоторые типы сетей OSPF не имеют DR и BDR, а у других есть особые условия, которые необходимо соблюдать.
Кроме того, они все одинаковые, правильно? 🙂
Не беспокойтесь, мы рассмотрим каждый тип сети OSPF, необходимый для сдачи экзамена CСNP ROUTE!
Если не указано иное, сегмент сети находится в зоне 0 — основной зоне.
Адрес подсети широковещательной сети — 10.1.1.0/24. Последний октет каждого IP адреса будет номером маршрутизатора. Каждый маршрутизатор имеет петлевой интерфейс, с номером маршрутизатора в каждом октете. (Петлевой интерфейс для R1 — 1.1.1.1/32 и т.д.)
Широковещательная сеть OSPF
Конфигурация OSPF в сегменте Ethernet для широковещательной сети будет оставлена по-умолчанию, также будут выбраны DR и BDR, для влияния на выбор DR/BDR можно использовать команду ip ospf priority.
Для большого сегмента сети хорошая идея использовать мощные маршрутизаторы для выполнения этих ролей (DR/BDR), так как это влечет за собой нагрузку на CPU. Как всегда, все, что мы делаем на маршрутизаторе имеет свою цену.
Вывод команды show ip ospf interface ethernet0 на маршрутизаторе R1 показывает нам тип сети, а также много другой информации. Заметьте, значения по-умолчанию hello- и dead- таймеров широковещательной сети — 10 и 40 секунд соответственно. По-умолчанию dead time равен четырехкратному hello time.
Для широковещательного сегмента не обязательно делать определенный маршрутизатор DR или BDR, но для нашего следующего примера это не так.
Сеть OSPF NBMA
Сейчас мы добавим еще сегмент к существующей сети, на frame relay. Новый сегмент использует адрес 172.12.123.0/24. От R1 идет два канала PVC до R2 и R3; между «спицами»(spoke) PVC нет. Интерфейс Serial0 каждого маршрутизатора находится в зоне 0.
Последовательные интерфейсы в этом новом сегменте по-умолчанию будут нешироковещательными с множественным доступом (NBMA). Так как узлы сети не образуют полносвязную сеть, хаб-маршрутизатор R1 должен быть DR и здесь может не быть BDR.
Почему? У DR и любого потенциального BDR должна быть возможность получать мультикаст от всех остальных маршрутизаторов в сети. В топологии «звезда» у spoke-маршрутизатора нет возможности получать широковещательный или мультикаст трафик от другого spoke-маршрутизатора, так как весь трафик проходит через хаб — а маршрутизаторы не перенаправляют широковещательный или мультикаст трафик!
Перед настройкой любой OSPF конфигурации поверх frame relay, убедитесь, что опция broadcast у вас включена!
Иначе OSPF пакеты не будут передаваться через frame relay.
Недостаточно просто убедиться, что R1 стал DR — мы должны предотвратить возможность становления DR/BDR для R2 и R3! Для этого изменим приоритет со значения по-умолчанию (1) на 0.
Маршрутизатор с наибольшим значением приоритета интерфейса, на котором включен OSPF, становится DR. Если значения приоритета равны, то сравниваются идентификаторы маршрутизаторов (RID), выигрывает — наибольший.
Фактически, мы мошенничаем с выбором DR, не оставляя шансов для spoke-маршрутизаторов, даже при исчезновении хаба! Установка приоритета в 0 для spoke-маршрутизаторов не оставляет им возможности стать DR в случае перезагрузки хаб-маршрутизатора.
«NB» в слове NBMA означает «нешироковещательный», так что при конфигурировании хаб-маршрутизатора нужно вручную указывать соседей, как показано ниже. Для spoke-маршрутизаторов такое не требуется.
У вас может быть сеть NBMA c DR и BDR, но они оба должны быть хаб-маршрутизаторами. Сеть с двумя хабами может использовать один как DR, другой как BDR. Каждый DR или BDR должен иметь статически настроенных соседей; такая настройка не нужна на других маршрутизаторах. (Если у вас много хаб-маршрутизаторов, один из них может быть BDR).
Заметьте, hello- и dead- таймеры равны 30 и 120 соответственно. Dead-таймер снова в четыре раза больше, чем hello.
Последовательные интерфейсы по-умолчанию NBMA, но вы можете изменить тип сети OSPF интерфейса командой ip ospf network.
Типы сетей OSPF Point-To-Point и Point-To-Multipoint
Сейчас мы добавим прямое соединение между R1 и R3, но расположим его в зоне 13. Номер подсети 172.12.13.0/27. Интерфейсы Serial1 обоих маршрутизаторов находятся в этой зоне 13.
Все non-backbone зоны должны иметь маршрутизатор с логическим или физическим интерфейсом в основной зоне 0. В зоне 13 два таких маршрутизатора, так что конфигурация правильная.
show ip ospf interface serial1 покажет данный сегмент OSPF по-умолчанию для типа сети OSPF point-to-point. Этот вывод показывает также по-умолчанию hello- и dead- таймеры для данного типа сети — 10 и 40 секунд соответственно.
Заметьте, что в списке нет DR и BDR. В канале «точка-точка» только два маршрутизатора. Следовательно, нет необходимости даже иметь DR или BDR, и ни один маршрутизатор не будет выбран в качестве таковых.
show ip ospf neighbor показывает прочерки на месте, где обычно указана роль соседа. Процесс выбора DR/BDR опускается в point-to-point и point-to-multipoint сетях. Команда neighbor обычно не нужна в этих сетях. Ниже R3 видит R1 как DR в сети NBMA, тогда как он же без роли видим в сети point-to-point.
Прочерк после FULL/ показывает, что сосед не является ни DR, ни BDR, ни DROther, что означает, что процесса выбора DR/BDR не было. Вы увидите подобную ситуацию в OSPF сети point-to-multipoint, что OSPF воспринимает, как набор каналов point-to-point.
Например, мы можем вернуться и изменить конфигурацию OSPF сети frame relay как сети point-to-multipoint командой ip ospf network point-to-multipoint на последовательном интерфейсе маршрутизатора R1. DR/BDR выбраны не будут и команда neighbor не нужна.
Теперь сеть OSPF типа point-to-multipoint предлагает два варианта — широковещательная и нет.
Конфигурация широковещательной OSPF сети Point-To-Multipoint
Этот тип сети не требует команды neighbor, но вы можете определить стоимость для данного соседа.
Заметьте, что опция broadcast отсутствует, так как по-умолчанию сети типа point-to-multipoint — широковещательные.
Нешироковещательная OSPF сеть Point-To-Multipoint
С другой стороны, в нешироковещательной сети point-to-multipoint команда neighbor требуется. Вы можете добавить стоимость для соседа, но соседи должны быть статически определены для данного типа сети.
Запуск широковещательных OSPF сетей над топологией NBMA
То, что вы можете что-то сделать, не означает, что вы должны это делать!
Нам следует использовать команду ip ospf network broadcast на всех маршрутизаторах сети frame relay, и, так как сеть полносвязная, технически все должно работать и маршрутизаторы будут вести себя так, как если бы были в LAN сети.
В реальной жизни использование широковещательной OSPF сети в сегменте NBMA может привести к непредсказуемым результатам, и лично я не стал бы так делать.
Зачем тратить время на устранение проблем, когда можно придерживаться настроек по-умолчанию?
Виртуальный канал (virtual link) OSPF
Настройки OSFP сети, запущенной через frame relay, были восстановлены до значений по-умолчанию для сети типа NBMA и останутся таковыми до конца данного раздела.
Сейчас мы добавим маршрутизатор R4 в нашу сеть. R4 и R3 будут соседями через зону 34, у R4 будет петлевой интерфейс в зоне 4. Адрес подсети для сегмента между R3 и R4 — 172.12.34.0/24, сегмент ethernet.
Результат данной конфигурации — неполные таблицы маршрутизации, что приводит нас к еще одному типу сетей OSPF. С зоной 34 проблем нет — один из маршрутизаторов с интерфейсом в этой зоне, также имеет физический интерфейс в основной зоне (R3).
Но в зоне 4 нет ни одного маршрутизатора с интерфейсом в зоне 0. Значит нужно сконфигурировать логическое соединение с зоной 0 — virtual link.
Так как у маршрутизатора R3 есть интерфейс в зоне 0, запуск виртуального канала между R3 и R4 позволит достичь полной связности в сети. Проблема в том, что у R1 нет маршрута до петлевого интерфейса R4, несмотря на то, что этот интерфейс был включен в OSPF.
Зона, через которую проходит виртуальный канал называется транзитной (transit area), она не может быть stub-зоной любого типа (stub, total stub, nssa) (Если вас раздражают все эти названия — не беспокойтесь, в данном курсе впереди еще будет много информации по ним!).
Вот команды для создания виртуального канала:
Виртуальные каналы должны быть сконфигурированы на обоих концах транзитной зоны. Сейчас перейдем к R3 и завершим конфигурацию.
И еще несколько деталей…
—Команда virtual link использует RID удаленного устройства, не обязательно IP адрес интерфейса, находящегося в транзитной зоне. Следите за этим — это очень распространенная ошибка. Проверяйте RID!
—Также не беспокойтесь насчет сообщений об ошибках в выводе команд R3, это нормально, вы будете видеть такие сообщения пока не закончите настраивать виртуальный канал. А вот если сообщения об ошибках появляются после настройки — то у вас проблема.
Всегда проверяйте виртуальный канал командой show ip ospf virtual-link. Если все настроено правильно, то он должен подняться за секунды.
Виртуальные каналы просто настраивать, но по какой-то причине они пугают людей. По моему опыту, сообщение об ошибке, как для маршрутизатора R3, вызывает панику, но все, что значит такое сообщение — только то, что настройка виртуального канала не закончена.
Знания рассеивают страх и панику.
99% ошибок при настройке виртуального канала вызывают следующие действия:
—использование неправильного значения RID
—попытка использовать stub-зону в качестве транзитной
—ошибка при настройке аутентификации для виртуального канала, в случае, когда зона 0 использует аутентификацию.
Этот третий случай выделен специально. Последнее всегда забывается! Виртуальный канал — это расширение зоны 0, и если зона 0 использует аутентификацию, она должна быть настроена и для виртуального канала тоже.
В этом разделе мы рассмотрели много команд OSPF, но не забывайте вашего старого друга — show ip protocols. Безотносительно типа сети, эта команда покажет вам маршрутизируемые сети, информацию об аутентификации для канала, и многое другое. Это замечательная команда для начала устранения проблем для любого протокола маршрутизации.
Не флуди!, или Что такое spam, flood и flame?
…Белка шишки собирает
И харды из них лабает,
А харды-то не простые,
Все дорожки золотые,
Все головки — изумруд…
Но, быть может, это флуд.
(Сказка о сисадмине и его сыне)
Все пользователи Интернета рано или поздно сталкиваются с такими явлениями, как spam, flood и flame.
Что такое спам
• spam (англ.) (кстати, если быть точным, надо говорить «спэм», а не «спам»!) — от SPiced hAM — 1) консервированный колбасный фарш (обычно свиной; запатентованное название); 2) любое консервированное мясо.
В интернет-жаргоне спам — это:
— практически бесполезная информация (как правило, коммерческая реклама сомнительного качества), принудительно рассылаемая большому числу пользователей электронной почты;
— принудительная выдача любой незапрошенной информации (самопроизвольное открытие новых окон браузера, принудительное перенаправление на другие сайты…).
• Спамер (spammer) — пользователь Сети, создающий и рассылающий спам.
• Спамить — заниматься рассылкой спама.
Что такое флуд
• flood (англ.) (кстати, если быть точным, надо говорить «флад», а не «флуд»!) — 1) наводнение, потоп, половодье, паводок; 2) подъем воды, прилив, переполнение; 3) поток, каскад; 4) изобилие, избыток, множество; 5) заливать, затоплять, наполнять; 6) подниматься (об уровне реки), выступать из берегов, разливаться; 7) поступить в изобилии, хлынуть потоком.
В интернет-жаргоне флуд — это:
— поток бессмысленной информации, заполняющий (заливающий, затапливающий!) коммуникационное пространство форумов, блогов, чатов, конференций (фактически, тот же спам);
— автоматически генерируемый трафик, забивающий сетевые каналы при DoS-атаках. «Зомбированные» хакерами компьютеры (так называемые «ботнеты») посылают ложные запросы на атакуемый сервер, пока тот под напором флуда не откажется работать;
— враньё, чушь, чепуха.
• Флудить (зафлудить) — заваливать форум (блог, чат, конференцию) бессмысленной информацией (например, сообщениями «не по теме»).
• Флудер — тот, кто занимается флудерством (флудит), злостный нарушитель общественного интернет-спокойствия (флудеров в Сети, как говорится, флуд флуди…).
• Флудерство (флужение) — занятие флудом (флуженье муз не терпит суеты!).
Что такое флейм
• flame (англ.) — 1) огонь, пламя; 2) горение, сгорание; 3) яркий свет; 4) блеск, яркость, великолепие; 5) пыл, страсть; 6) предмет любви, предмет обожания; 7) гореть ярким пламенем, пылать; 8) разразиться (чем-либо), «взорваться»; 9) вспыхнуть, покраснеть; рдеть, пылать (например, о щеках).
В интернет-жаргоне флейм — это:
— оживленное обсуждение какого-либо вопроса в Сети, обычно начинающееся с чьего-либо «зажигательного» сообщения, письма, реплики.
— «наезд» (ругань в Сети в чей-либо адрес).
• Флеймить — спорить не по существу, прибегать не к аргументам, а к обыденной брани и оскорблениям, переходя от темы дискуссии на личность оппонента («Сам дурак»!).
• Флеймование — занятие флеймом.
Примечания
1. Флейм, как правило, более агрессивен, чем флуд и спам.
2. Самый назойливый из всей «святой троицы» — спам.
3. Спам, флуд и флейм — «близнецы-братья», они органически дополняют друг друга, образуя в Сети так называемый «мусорный трафик».
FLOOD_WAIT_* not handled well #135
Comments
himselfv commented Jan 16, 2018 •
I’ve looked at the code, and it seems this is supposed to be handled in tgl, by rescheduling the request to a later time.
But I’ve added printfs in timer callbacks and the timer is immediately freed after being rescheduler. Later in the same tgl_query_error this indeed happens:
res is 0 from the start of the function and nothing in FLOOD_WAIT branch changes it. In other similar cases where the function handles the error, it sets res to 1. Maybe it should also be set to 1 here?
Tentatively I’ve added
queries.c > alarm_query() has two routes which I’m not sure mean what, I’ve checked that the execution goes the first route. This is where I’m stuck so far. Any ideas? Thank you.
Also I don’t know Telegram protocol very well so maybe I’m wrong, but is it enough to just reschedule the query that triggered the FLOOD_WAIT? Shouldn’t the following queries be also delayed?
I mean, say you have 20 queries coming one after another and Telegram says FLOOD_WAIT on the sixth one, this reschedules it N seconds later, but wouldn’t tgl still try to send queries number 6, 7 and so on? I imagine if this was all a single connection, it would get FLOOD_WAIT for each of them, and by the time the first rescheduled request fires and is re-sent the connection is still flooded (since each successive FLOOD_WAIT shifts the wait window further), and it’ll get FLOOD_WAIT again and so on. I’m not actually observing this, just wondering.
The text was updated successfully, but these errors were encountered: