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.
Code: Select all
придумал на своем шлюзе топорное решение, которое позволяет обойти указанный глюк при репликации данных баз :) я тупо ограничил производительность потока, занимающегося DDB до 20 tps
Всем теперь нужно заново зарегистрировать свои станции на узлах. Для тех, у кого "желтенькое" до сих пор - перезагрузите WinDV.