Хуже всего, что никаких метрик на этот случай не предусмотрели. Отловить источник проблемы можно лишь догадавшись, почему такое странное ограничение (20), или через запуск strace на процессе, который лишь покажет, что setsockopt с опцией IP_ADD_MEMBERSHIP по какой-то причине возвращает ошибку ENOBUFS.
Используется именно MAX, а не AND. При проверке используется макрос IN_DEV_RPFILTER, который в свою очередь использует макрос IN_DEV_MAXCONF, который уже использует макрос max. У переменных sysctl подобная логика может различаться. Для уточнения лучше читать либо документацию, либо исходники.
Есть одна особенность, которая не позволяет отключить данным образом rp_filter. Дело в том, что применяется значение max(all, <iface>), т.е. если у вас в конфиге интерфейса net.ipv4.conf.${iface}.rp_filter = 1, а net.ipv4.conf.all.rp_filter = 0, то для интерфейса будет использоваться значение rp_filter = 1. Правильнее не отключать rp_filter совсем, а использовать так называемый loose-режим, который смягчает правила rp_filter, и будет отбрасывать пакеты лишь в том случае, если до источника этих пакетов вообще нет маршрута. Если же маршрут до источника есть, но он не совпадает с интерфейсом, на который пришли пакеты, то они всё равно будут пропущены, а не отброшены, как при rp_filter = 1 (strict-режим).
По-моему, диагностику лучше всего начинать с просмотра статистики через nstat -az. В кейсе 1 сразу можно было бы увидеть инкрементирование счётчика TcpExtIPReversePathFilter (количество отброшенных rp_filter-ом пакетов), а в кейсе 2 — TcpExtTCPTimeWaitOverflow. Третий кейс интересный, и я когда-то тоже натыкался на это ограничение по-умолчанию на сервере, который работал с кучей мультикаст групп.
Технически REDIRECT является подвидом DNAT, с той лишь разницей, что адрес назначения (destination) переписывается на primary-адрес интерфейса, с которого получен пакет (вот так это реализовано для IPv4 и для IPv6). Локальные же пакеты будут перенаправляться на порт на адресе 127.0.0.1. Отсюда следует одна неочевидная особенность — если вы перенаправляете пакеты на какой-то порт, но ваше приложение не слушает порт на интерфейсе, на который пришёл пакет, то ничего не заработает — счётчики на правиле будут увеличиваться, но в ответ клиенту будут улетать tcp-reset'ы или icmp-port-unreachable (если там UDP). Точно так же, например, не получится перенаправлять входящие извне пакеты приложению, которое слушает только 127.0.0.1. Если же на интерфейсе нет адреса вообще (например, если вы используете unnumbered-интерфейс), то пакеты будут отброшены. И так как это завязано на коннтраке, то не забывайте очищать таблицу коннтрака после изменения правил; а так же учтите, что под это правило попадают только пакеты соединений с состоянием NEW, то есть только первый пакет соединения, которого ещё нет в таблице коннтрака. Отловить же эти пакеты в других цепочках можно через конструкцию "-m conntrack --ctstate DNAT". Вот как-то так.
Cake — ещё одна дисциплина очереди, которая разрабатывается в рамках проекта bufferbloat. Подробнее тут.
Cubic — один из алгоритмов управления перегрузкой (congestion control) в tcp. Используется по-умолчанию. Статья в википедии.
В tc реализованы как policer, так и shaper трафика. Причём алгоритмов шейпинга несколько, с различными возможностями и сложностью настройки. Это именно шейперы, которые в случае необходимости, «придерживают» пакеты в буфере, выравнивая скорость передачи данных. Алгоритмы контроля перегрузки (congestion control) протокола TCP на конечных хостах уже после подстраиваются под задержки и потери сегментов, замедляя и ускоряя передачу данных.
Вы так говорите, как будто в одиночку всем этим занимались. Судя по Вашему профилю и стилю общения, Вы управленец, а не инженер. Лично у меня предвзятое отношение к призам для управленцев, которые выдаются другими управленцами.
Дедупликация аттачей? Вы серъёзно?! Как вы это себе представляете? На самом деле вложения являются составной частью тела письма. Для интереса можете в своём почтовом клиенте посмотреть исходное представление письма с вложением, чтобы убедиться в этом.
Даже не очень ясно, с чего Вы решили, что сможете осилить такую задачу, как приблизительный расчёт затрат на реализацию обязаловки, введённой этими поправками. Судя по всему, технарь и математик из Вас никакой, но, к сожалению, вот только к таким и прислушиваются наши законотворцы. Приходите после того, как наберётесь достаточным объёмом знаний.
А в чём смысл статьи так и осталось непонятным. Для чего нам нужно знать, уникальна ли колода после тасования или нет? Ведь исход игры зависит не только от комбинации и положения карт в колоде, но и от действий игроков, в случае, если разрабатывается стратегия.
Как мне кажется, вся вышеперечисленная выкладка из разряда бесполезных фактов.
После пары версий, сломанной осталась лишь раскраска табов, причём очень интересно сломана: раскраска появляется, если открыто окно «Customize», а так же в приватном окне. Personal Menu на линуксе работает как и прежде, но в Винде нет возможности что-то поменять — пустое окно настройки. По поводу TabMixPlus в многострочном режиме: есть возможность ограничить число строк, после их заполнения будет доступна прокрутка вертикальная прокрутка строк табов, которая очень клёво листает эти самые строки. Так же желательно делать ограничивать ширину табов, чтобы они ровно друг под другом находились.
Да, сможет. Ставьте Classic Theme Restorer (CTR) и в добрый путь. Единственное, что огорчает, так это сломался адд-он Personal Menu, позволяющий редактировать выпадающее меню FirefoxButton. Так же лично у меня сломалась покраска табов из настроек TabMixPlus, но не беда — на праздниках поправлю.
Вот так, всего лишь одним постом можно целиком перечеркнуть все свои предыдущие заслуги. Печально, что вроде бы и человек не глупый, а такую ересь предлагает.
Хуже всего, что никаких метрик на этот случай не предусмотрели. Отловить источник проблемы можно лишь догадавшись, почему такое странное ограничение (20), или через запуск
straceна процессе, который лишь покажет, чтоsetsockoptс опциейIP_ADD_MEMBERSHIPпо какой-то причине возвращает ошибкуENOBUFS.Используется именно MAX, а не AND. При проверке используется макрос IN_DEV_RPFILTER, который в свою очередь использует макрос IN_DEV_MAXCONF, который уже использует макрос max. У переменных sysctl подобная логика может различаться. Для уточнения лучше читать либо документацию, либо исходники.
Есть одна особенность, которая не позволяет отключить данным образом rp_filter. Дело в том, что применяется значение
max(all, <iface>), т.е. если у вас в конфиге интерфейсаnet.ipv4.conf.${iface}.rp_filter = 1, аnet.ipv4.conf.all.rp_filter = 0, то для интерфейса будет использоваться значениеrp_filter = 1. Правильнее не отключатьrp_filterсовсем, а использовать так называемый loose-режим, который смягчает правилаrp_filter, и будет отбрасывать пакеты лишь в том случае, если до источника этих пакетов вообще нет маршрута. Если же маршрут до источника есть, но он не совпадает с интерфейсом, на который пришли пакеты, то они всё равно будут пропущены, а не отброшены, как приrp_filter = 1(strict-режим).По-моему, диагностику лучше всего начинать с просмотра статистики через
nstat -az. В кейсе 1 сразу можно было бы увидеть инкрементирование счётчикаTcpExtIPReversePathFilter(количество отброшенных rp_filter-ом пакетов), а в кейсе 2 —TcpExtTCPTimeWaitOverflow. Третий кейс интересный, и я когда-то тоже натыкался на это ограничение по-умолчанию на сервере, который работал с кучей мультикаст групп.Cubic — один из алгоритмов управления перегрузкой (congestion control) в tcp. Используется по-умолчанию. Статья в википедии.
А про какую из книг Дональда Кнута Вы говорите?
Как мне кажется, вся вышеперечисленная выкладка из разряда бесполезных фактов.