[alibek]

1 минуту назад, snik_1900 сказал:

т.е. если были пропущены несколько "дель" и вместо очередной "дельты" скачен полный реестр при следующем запросе все равно оператор получит все дельты?

Нет.

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

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

[ligverd]

2 минуты назад, snik_1900 сказал:

т.е. если были пропущены несколько "дель" и вместо очередной "дельты" скачен полный реестр при следующем запросе все равно оператор получит все дельты?

Бррр, не понял. :)

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

[alibek]

4 минуты назад, snik_1900 сказал:

Это при условии что не проводить опрос DNS-серверов.

А причем тут это?

Получение реестра это одна задача, фильтрация по реестру это другая задача.

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

Самостоятельный ресолвинг имен скорее всего вообще уйдет в прошлое, придется использовать DPI и проверять содержимое пакетов.

[ligverd]

3 минуты назад, alibek сказал:

Нет.

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

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

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

 

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

Думаю раз в сутки лучше скачать полный список.

[alibek]

Что-то чую я, что не взлетит.

В текущем виде эта схема нежизнеспособна.

Скорее всего до конца года будет еще куча изменений.

[Стич]

Интересно а много ли DPI умеют добавлять и удалять нужные строки?

А то всё равно это будет подготовка нового конфига и заливка в DPI,

то есть тоже что и было до введения дельт.

 

Особено весело будет когда один IP или URL или Домен встречаются в нескольких записях,

а судя по состоянию реестра на сегодняшний день, будет точно.

Изменено 17 ноября, 2017 пользователем Стич

[ligverd]

Только что, alibek сказал:

Что-то чую я, что не взлетит.

В текущем виде эта схема нежизнеспособна.

Скорее всего до конца года будет еще куча изменений.

:)

да нет схема нормальная, я только боюсь за доступность сервера и за понижение планки на время реагирования.

 

1 минуту назад, Стич сказал:

Интересно а много ли DPI умеют добавлять и удалять нужные строки?

А то всё равно это будет подготовка нового конфига и заливка в DPI,

то есть тоже что и было до введения дельт.

+1

Вот это правильная плоскость обсуждения, а протокол дельт довольно сносный.

[DimaM]

43 минуты назад, ligverd сказал:

Интересно а много ли DPI умеют добавлять и удалять нужные строки?

IMHO на стороне dpi поддержка дельт - это лишнее:

загрузить с локального диска полный список на dpi занимает сотые доли секунды, что там можно сэкономить ?

[alibek]

1 минуту назад, DimaM сказал:

загрузить с локального диска полный список на dpi занимает сотые доли секунды, что там можно сэкономить

Не знаю, возможно с облачным списком дела обстоят иначе.

Но с custom-списками необходимо делать рестарт (reload недостаточно), что занимает один-два десятка секунд.

[ligverd]

1 час назад, pety сказал:

А операторов, которые не захотят сильно заморачиваться и будут запрашивать реестр только целиком, будут штрафовать? Ведь как-то не хорошо давать ограничение (например) - полный реестр только раз в сутки, остальное дельта. Потеряете полный вариант - Ваши проблемы.

А вот тут уже "Личный кабинет" + капча, есть уже отчет по забору дельт, только предупредили что пока статистика не заносится в ЛК, но контролироваться будет забор и полного реестра и дельт.

Как обещали в конце концов будут штрафовать только за не закрытие ресурса а не за не забор реестра, но когда это случится забыли сказать.

[YuryD]

 Я уже орал про незабор реестра в форуме ската. И вот теперь какая-то очередная хрень. Писем и рекомендаций пока никаких не получал, так что гадаю по кофейной гуще  комментариям тут.

 

 Далее - занесение урлов в реестр на чем-то основано. Есть конторы, решающие занести в реестр, и заносящие - и это как правило люди. Процесс принятия решения в общем известен, суд там, или что еще типа комиссии. Люди не железные, и не смогут принимать решения раз в минуту, а от нас требуют реакцию на решение за минуту. Смысл такого реагирования какой ? Т.о. мне мнится просто какой-то робот, сам принимающий решение. Соотв это вам будет даже не бунт машин иот, а нечто более ужасное.

[ligverd]

Мы тоже в недоумении. В интернете тишина полная.  Где информация?

Или нас (как выясняется некоторых) жестоко на^%$# :(

При чем данный алгоритм якобы умоляли внедрить магистральные провайдеры и они уже все готовы. :-/

[YuryD]

 Основная идея - как я понял здесь - повысить скорость реакции на блок ресурса. Если учесть, что решения принимает суд, или комиссия - то они работают только в рабочее время. Соотв какая нах разница, заблочили через 8-36 часов, и 8-36часов+1 минута ? Это будет работать, если решение о блокировке принимает железный человек, умеющий за минуту проанализировать урл, и абсолютно разобраться во всех деталях описанных. Работающий 24*7*365 плюс еще 146%

[st_re]

23 минуты назад, YuryD сказал:

 

Да к марту они готовятся...

Скорее всего надо чтобы можно было быстро рубить...

а так там можно вплоть до 0.0.0.0/0 прислать, если припрет..

[YuryD]

5 минут назад, st_re сказал:

Да к марту они готовятся...

Скорее всего надо чтобы можно было быстро рубить...

а так там можно вплоть до 0.0.0.0/0 прислать, если припрет..

 Именно это я и имел ввиду. Вся надежда на производителей дпи, они-то сук, на котором сидят, не спилят. Хотя-бы идея про белые списки ими вроде реализована. А готовиться к марту - глупо, результат в общем известен, хотя бы в стиле "я устал и ухожу". Но это политота, и ей у нас не место. Но тут и законные методы есть - например слегка расширить понятие "день тишины перед выборами" на интернет.

[Sergey Gilfanov]

5 часов назад, alibek сказал:

И пусть даже на каждый запрос не нужно формировать дельту, но определять нужную (заранее сформированную) дельту придется для каждого запроса.

Так что сервис от статики переходит к динамике, что на производительности скажется не лучшим образом.

Тоже мне динамика. Грубо говоря - серверу нужно закешировать ответы на запрос "отдай список дельт с даты yyyymmdd-HHMM".  Один раз сгенерировал - и в течении следующих 10 минут можно всем не глядя из кеша отдавать. На границе 10 минут кэш устаревает и генерируется новый список. Причем большинство запросов будет "на отдай мне изменения с предыдущих 10 минут", т.е. один и тот же. Попадание в кэш будет почти сто процентным.

[st_re]

Ну это же не мешает геренировать сейчас каждому по xml файлу временами минут по 5. сейчас то файлы одинаковые (ну или если сейчас не одинаковые то и далее будут разные дельты.) Что мешает нагенерить файл раз в 5 минут и отдавать его через accel-redirect по реультату проверки подписи в запросе? Не подпись же проверять 5 минут ? Если выгрузка не изменилась, то файл не менять.. тогда даже иф модифай отработает и вернет 304.

Но нет жеж, надо было какогото монстра неповоротливого нарожать. 

 

Если дяди не в состоянии минимальную проверку УРЛа сделать, и лепят туда несовместимый с РФС и жизнью мусор, а все 30к провайдеров должны за ними подчищать? Эти люди не смогут сделать систему которая работает нормально, пока туда не придет ктото понимающий специфику работы веба вообще и написания веб приложения под, в общем то, небольшую нагрузку.

[YuryD]

 Для проверок lastdumpdate подпись не нужна, вроде так. Нужна только для выгрузки. Дергать запросом про getlastdumpdate можно и раз в минуту - если их железяка справится.

[Alex/AT]

Пока что, если честно, проще запрашивать каждый час полную выгрузку, как и раньше.

[Andrei]

1 час назад, Alex/AT сказал:

Пока что, если честно, проще запрашивать каждый час полную выгрузку, как и раньше.

+1. И "положить" на сложности с дельтами

[snik_1900]

ID=707570 Только у нас криво закрывается? Или у кого-то ещё такая же проблема?

[sfenixs]

В 22.11.2017 в 09:05, snik_1900 сказал:

ID=707570 Только у нас криво закрывается? Или у кого-то ещё такая же проблема?

Есть такая беда :) придется по домену прикрыть

[Andrei]

Я как-то перестал понимать логику работы Ревизора: сегодня появились пропуски, хотя ни вчера, ни позавчера их не было и систему блокировки я не трогал. Смотрю когда сайты, указанные как пропуски, внесены в реестр - аж в 2016 году. Где логика работы?

[alibek]

Смотрите диффы дампов. Иногда в старые записи добавляют новые адреса.

[Tosha]

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

Загрузка "диффа" - определить что нужно удалить "строку" - получить "лок", изменить структуру данных, снять "лок" и так по циклу для каждой строки.  В лучшем случае подготовить новую структуру отдельно и действовать по старой схеме.

 

Узкое место - сколько придется "лочить" структуры данных. Т.е. проблема не в размере операций, а от их количества.

Не вижу от "диффов" никакой эффективности. Только возможные проблемы что-то упустить а то и столкнуться с тем, что DPI не умеет редактировать списки на лету в принципе. А если и умеет, то в разы с большей для себя нагрузкой.