Свежие комментарии

Нет, я не понимаю.
Вот есть адрес 8.0.0.1 (можно его в двоичном виде записать, ничего не изменится, как было 32 бита, так и останется).

Он не равен ни одному из перечисленных выше префиксов:
===
8.0.0.0/8 - хороший
8.0.0.0/16 - плохой
8.0.0.0/24 - хороший
8.0.0.11/32 - плохой
8.0.16.0/24 - хороший
===

Как узнать что он хороший, а 8.0.1.0 - наоборот плохой?

У них же новые хозяева. Вот и перетряхивают все сервисы.

"годность" идеи касалась только запросов и только в одну сторону - проверка на "вшивость" из www-frontend'а. и даже в этом случае при более-менее высокой нагрузке один SQL-бэкенд не справится (будь он хоть sqlite'ом - там тоже дикое похмелье при единичных обновлениях и большом потоке одновременных запросов на чтение). результат - либо могучая кучка инстансов SQL-серверов с бесплатно прилагающимися развлечениями в виде репликаций (и дай бог, чтобы только с единственным master'ом), либо дальнейшие поиски философского камня.

а если же при этом есть задача ещё и одновременно собирать статистику (т.е. фиксировать факт lookup'а) - то явно будут другие идеи :)

хотя... и в этом случае прыжки и ужимки с lua отнюдь не лишены смысла. например, инкрементировать счётчик для конкретного ip'а с префиксом в виде текущего часа, а раз в час по cron'у выполнять SQL-запрос, агрегирующий собранную статистику и обновляющий BL как в SQL, так и во внешних хранилищах.

http://stackoverflow.com/questions/9989023/store-ip-ranges-in-redis

беда же, однако, в том, что нет простого способа обновить данные во внешнем хранилище при обновлении данных в postgresql. updatable foreign data wrapper есть только для самого же postgresql (да даже если бы он и был для redis'а, вряд ли бы там "из коробки" была поддержка команд zadd/zrange/z*), поэтому остаётся упражняться с pl/perl или pl/python или возвращаться к cron'у.

хотя сама по себе идея явно годная - иметь основное хранилище IP ranges в SQL, lookup к которому был бы максимально дешевым и годным для high-load. чисто теоретически такое можно было бы сделать на ngx_lua (размещая, например, суррогат radix tree в redis/memcache).

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

Я редиску только начал крутить, так что возможны более удачные варианты. Но я делал-бы что-то вроде ревёрс индекса:
1. Определиться с приоритетами правил, формирования их ключей и с порядком их "удалённости" от некого конкретного ip.
2. Сделал-бы функцию генерящую по выданному ip однозначную и упорядоченную пачку ключей для соответствующих ему правил. Например (в порядке от ближе к дальше) для ip 8.1.16.3/24 пачка была-бы примерно такой:
spam:ip:8.1.16.3/24
spam:ipgroup:8.1.16.3
spam:ipgroup:8.1.16.0/24
spam:ipgroup:8.1.16.0
spam:ipgroup:8.1.0.0/24
spam:ipgroup:8.1.0.0
spam:ipgroup:8.0.0.0/24
spam:ipgroup:8.0.0.0
3. Для любого ключа имеем 3 варианта значения: пусто(get возвращает nil)/да/нет
4. Правила кладём set-ом вида
set spam:ip:8.1.16.3/24 true
или
set spam:ipgroup:8.1.0.0/24 false
5. Проверяем одним mget-ом (multi-get) со всем списком из 2. с последующим поиском в рез-те первого не нила (редиска порядок держит жестко).

В минусе этого подхода рост длинны пачки в 2. для каждого проверяймого ip при добавлении новых типов правил. Но при общей скорости редиски, количестве конкретных вбитых да/нет правил в районе до тысяч, и даже пусть десятках тысяч запросов в день я не думаю, что по производительность будет какой-то проблемой. (В крайнем разе проверку в редисном серверном скрипте делать можно).

Для непускания излишне активных ip-шников можно пользовать ключи с ttl-ем. Делается в 2 комманды:
set spam:ipactive:8.1.16.3/24 0
expire spam:ipactive:8.1.16.3/24 1000
И, соответственно, если по get-у не nil, то отлупить.

Может привычки нету, а не китайская.

Старая барахолка у меня была в RSS-ридер заведена и читалась вместе с прочими новостями.
Новую просматривать формально даже удобнее, но если я ничего специального не хочу, то ходить туда не будешь же.

Наблюдаю на границе Московской области - карты гугла прорисованы точно с OSM,
выглядит несравненно лучше карт яндекса, и относительно близко к народным картам.

Да, с конкурентами были приколы.

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

Сложный вопрос. Работали под тем же брендом, завлекая новых клиентов, активно подтирая все упоминания о конкурентах. По-моему весьма близкая связь.

Насчет альтернатив, не настолько часто продаю/покупаю, пока хватало сообществ в ЖЖ и авито. Вконтактик, наверное тоже, не пробовал - не знаю.

туда им и дорога (фото.с ру). Уже давно проголосовал рублем. Да и свято место пусто не бывает.

Я вот почитал для общего развития (идеи использовать REDIS нет, но почитал), нашел как в редиску пихают базу geodb

Я правильно понимаю, что если у меня вложенные префиксы, ну там:
8.0.0.0/8 - хороший
8.0.0.0/16 - плохой
8.0.0.0/24 - хороший
8.0.0.11/32 - плохой
8.0.16.0/24 - хороший

То мне придется такую базу развернуть в линейную последовательность IP-адресов и пихнуть в тамошний ordered set

А Native IP-с-масками (и, соответственно, возможность работы с вложенными ranges) - редисом не поддерживается?

Не, не куплен, мне к новому году оба.

У ламп садится яркость. Мой 2180UX (не помню сколько ему лет, скажем 8, потому что 30" уже пять) калибруется сейчас только на 100 cd/m^2, а был молодым - мог не меньше 140.

Надо туда будет добавить пример конфигурации, когда ограничивается не всё, да.

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