"Желтенький" ircDDB в WinDV сегодня: разбор полетов

Moderator: BM Administration

Post Reply
User avatar
R3ABM
Posts: 3105
Joined: 08 Jun 2012, 07:43

"Желтенький" ircDDB в WinDV сегодня: разбор полетов

Post by R3ABM » 16 Aug 2012, 23:39

Так, чтоб вы знали. Не хочу сейчас причесывать текст и описывать заново. Приведу выдержку моей беседы в Скайпе с DL3OCK:

Code: Select all

[15.08.12, 18:54:00] Artem Prilutskiy: увидел концептуальную багу ircddb, попозже опишу
[15.08.12, 18:54:13] Artem Prilutskiy: не то чтоб увидел, а воткнулся в нее :)
[16.08.12, 9:58:08] Artem Prilutskiy: Значит, проблема следующего характера:
[16.08.12, 10:00:09] Artem Prilutskiy: репликация таблиц в ircDDB происходит запросом SENDLIST <номер таблицы> <дата-время записи, с которой должны начинаться события в списке>
[16.08.12, 10:01:00] Artem Prilutskiy: В ответ выдается список из записей, количеством до 30
[16.08.12, 10:01:20] Artem Prilutskiy: после этого сообщение LIST_MORE или LIST_END
[16.08.12, 10:02:06] Artem Prilutskiy: внимание вопрос: что будет, если в течение секунды ircDDB зарегистрировала более 30 обновлений?
[16.08.12, 10:04:12] Artem Prilutskiy: 1) если шлюз забирает записи максимально стараясь ничего не пропустить, в качестве параметра даты-времени он задает дату последней известной в его локальной таблице записи... Когда записей на одну секунду времени в ircDDB больше 30, шлюз уходит в цеклический перезапрос данных...
[16.08.12, 10:05:39] Artem Prilutskiy: можно, конечно, сделать "костыль", когда каждый последующий запроос будет запрашивать данные на секунду позже, чем последняя известная дата... но в таком случае будет потеря данных при чтении
[16.08.12, 10:06:31] Artem Prilutskiy: я не знаю, как эту проблему лучще передать мишелю. сейчас оно у него работает, по скольку скважность в 30 сообщений не достигнута в "большом" ircDDB
[16.08.12, 10:07:46] Artem Prilutskiy: есть элегантное решение проблемы без изменения самого протокола, которое нужно реализовать на сервере:
[16.08.12, 10:10:32] Artem Prilutskiy: нужно вычислять его установленный лимит NUM_ENTRIES исходя из максимального количества обновлений на единицу времени... да, это усложнит его код. но хоть такой фигни не будет, какая есть сейчас
[16.08.12, 10:12:26] Artem Prilutskiy: уперся я в это дело, когда переливал данные из большой IRCDDB в нашу маленькую. получилось поболее 30 обновлений для таблицы 2 и у меня клиент "встал раком". Хорошо, что WinDV и G4KLX не тянут к себе таблицу 2.
Вот как раз в такую ситуацию, похоже, попал WinDV, после чего засветил желным и показал Status 2. К счастью, я придумал, как обойти такую ситуацию при репликации данных.

Code: Select all

придумал на своем шлюзе топорное решение, которое позволяет обойти указанный глюк при репликации данных баз :) я тупо ограничил производительность потока, занимающегося DDB до 20 tps
Стер все таблицы в нашем ircDDB, поставил обновленную версию BG и перелил все данные из "большого" ircDDB заново.
Всем теперь нужно заново зарегистрировать свои станции на узлах. Для тех, у кого "желтенькое" до сих пор - перезагрузите WinDV.
R3ABM / DL5ABM / ex. UB3ABM

UC3B
Posts: 1139
Joined: 08 Jun 2012, 13:53

Re: "Желтенький" ircDDB в WinDV сегодня: разбор полетов

Post by UC3B » 16 Aug 2012, 23:41

Ну ты даешь... стране - угля... :)
Молодец... :)

User avatar
R3ABM
Posts: 3105
Joined: 08 Jun 2012, 07:43

Re: "Желтенький" ircDDB в WinDV сегодня: разбор полетов

Post by R3ABM » 17 Aug 2012, 08:53

Смотрите как будет дальше. Сегодня немного изменил алгоритм троттлинга.
R3ABM / DL5ABM / ex. UB3ABM

User avatar
R3ABM
Posts: 3105
Joined: 08 Jun 2012, 07:43

Re: "Желтенький" ircDDB в WinDV сегодня: разбор полетов

Post by R3ABM » 18 Aug 2012, 11:58

Хм :) А новый алгоритм эффективно работает :)
Вот пример:

Code: Select all

Aug 18 06:51:16 maia bordergate: A: registering STN460  
Aug 18 06:51:16 maia bordergate: A: registering STN460 X
Aug 18 06:51:16 maia bordergate: A: registering STN461  
Aug 18 06:51:16 maia bordergate: A: registering STN461 X
Aug 18 06:51:16 maia bordergate: A: registering STN462  
Aug 18 06:51:16 maia bordergate: A: registering STN462 X
Aug 18 06:51:16 maia bordergate: A: registering STN463  
Aug 18 06:51:16 maia bordergate: A: registering STN463 X
Aug 18 06:51:16 maia bordergate: A: registering STN464  
Aug 18 06:51:16 maia bordergate: A: registering STN464 X
Aug 18 06:51:16 maia bordergate: A: registering STN465  
Aug 18 06:51:16 maia bordergate: A: registering STN465 X
Aug 18 06:51:16 maia bordergate: A: registering STN466  
Aug 18 06:51:16 maia bordergate: A: registering STN466 X
Aug 18 06:51:16 maia bordergate: A: registering STN467  
Aug 18 06:51:16 maia bordergate: A: registering STN467 X
Aug 18 06:51:16 maia bordergate: A: registering STN469  
Aug 18 06:51:16 maia bordergate: A: registering STN469 X
Aug 18 06:51:16 maia bordergate: A: registering STN031  
Aug 18 06:51:16 maia bordergate: Limit of registrations number exceeded
Aug 18 06:51:17 maia bordergate: A: registering STN031 X
Aug 18 06:51:17 maia bordergate: A: registering STN468  
Aug 18 06:51:17 maia bordergate: A: registering STN468 X
Применяем подход, напоминающий решения неопытных разработчиков, но, на самом деле куда более глюбокомысленный, ломающий шаблон :) Все операции по обновлению баз DDB выполнены в виде отдельного потока. Считаем только операции, требующие нотификации серверов. При привышении лимита tps, происходит пинальти в виде секундного ожидания на ввод/вывод. Такое решение позволяет отказаться от создания прикладного уровня очередей на шлюзе, все компенсируется только транспортными очередями на серверах irc.
R3ABM / DL5ABM / ex. UB3ABM

Post Reply

Return to “Технические аспекты D-STAR”