По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Что такое парадигмы программирования? Это не более, чем просто замысловатое название для популярных способов и стилей организации процесса написания программного кода.
Я постараюсь разбить эту тему на части и дать простое пояснение по каждой парадигме. Таким образом, вы сможете легко понять, о чем говорят люди, когда произносят такие слова, как «объектно-ориентированный», «функциональный» или «декларативный». Давайте начнем!
Что такое парадигма программирования?
Парадигмы программирования – это различные способы и стили, которые используются для организации программы или языка программирования. Каждая парадигма состоит из определенных структур, функций и взглядов на то, как следует решать известные задачи программирования.
Вопрос о том, почему существует так много различных парадигм программирования, схож с вопросом о том, почему существует так много языков программирования. Определенные парадигмы лучше подходят для определенных типов задач. Именно поэтому имеет смысл использовать разные парадигмы для разных типов проектов.
Кроме того, методики, которые составляют каждую парадигму, развивались с течением времени. Благодаря достижениям как в области программного, так и аппаратного обеспечения появились различные подходы к решению задач, которых раньше просто не было.
И последняя причина – я думаю, это просто творческое начало в человеке. По своей натуре, нам просто нравится создавать новые вещи, улучшать то, что другие когда-то создали, и адаптировать инструменты под себя и свои предпочтения или просто делать их более эффективными (в нашем понимании).
Все это привело к тому, что на сегодняшний день мы имеем огромное количество вариантов, которые могут помочь нам написать и структурировать ту или иную программу.
Чем парадигма программирования не является?
Парадигмы программирования – это не языки и не инструменты. Вы не сможете ничего «создать» с помощью парадигмы. Они больше похожи на некий набор образцов и руководящих принципов, о которых условились большое количество людей, которым они следовали и которые они подробно изложили.
Язык программирования не всегда привязан к определенной парадигме. Есть языки, которые были созданы с учетом определенной парадигмы и имеют функции, которые облегчают программирование в этом контексте больше, чем другие (хороший пример – Haskel и функциональное программирование).
Однако существуют и «многопарадигмальные» языки. Это означает, что вы можете адаптировать свой код, чтобы он подходил под какую-то из парадигм (хороший пример – JavaScript и Python).
При этом парадигмы программирования не являются взаимоисключающими в том смысле, что вы можете без каких-либо проблем использовать приемы из различных парадигм одновременно.
Популярные парадигмы программирования
Теперь, когда вы знаете, что такое парадигмы программирования, а что к ним не относится, давайте рассмотрим самые популярные из них, их характеристики и сравним их.
Имейте в виду, что этот список не полный. Существуют и другие парадигмы программирования, которые мы здесь рассматривать не будем. Здесь я расскажу вам только о самых популярных и широко используемых.
Императивное программирование
Императивное программирование – это набор подробных инструкций, которые даются компьютеру, чтобы тот выполнил их в заданном порядке. Этот тип программирования называется «императивным», потому что мы некоторым образом указываем компьютеру (как программисты), что он должен делать.
Императивное программирование концентрируется на описании того, как программа работает, шаг за шагом.
Допустим, вы хотите испечь торт. Ваша императивная программа для такого рода задачи может выглядеть следующим образом:
1- Pour flour in a bowl
2- Pour a couple eggs in the same bowl
3- Pour some milk in the same bowl
4- Mix the ingredients
5- Pour the mix in a mold
6- Cook for 35 minutes
7- Let chill
Воспользуемся конкретным примером и предположим, что мы хотим отфильтровать массив чисел так, чтобы остались только числа, которые больше 5. Наш императивный код тогда будет выглядеть следующим образом:
const nums = [1,4,3,6,7,8,9,2]
const result = []
for (let i = 0; i < nums.length; i++) {
if (nums[i] > 5) result.push(nums[i])
}
console.log(result) // Output: [ 6, 7, 8, 9 ]
Обратите внимание, что мы указываем программе, что нужно перебрать каждый элемент массива, сравнить каждый из них с 5 и, если элемент больше 5, то поместить его в конечный массив.
Наши инструкции предельно детализированы и конкретны, и именно это и является императивным программированием.
Процедурное программирование
Процедурное программирование – это производное от императивного программирования только с функциями (также известных как «процедуры» или «подпрограммы»).
Процедурное программирования предлагает пользователю разделить выполнение программы на функции, чтобы оптимизировать модульный принцип организации.
Вернемся к нашему примеру с тортом. Процедурная программа для этого примера будет выглядеть следующим образом:
function pourIngredients() {
- Pour flour in a bowl
- Pour a couple eggs in the same bowl
- Pour some milk in the same bowl
}
function mixAndTransferToMold() {
- Mix the ingredients
- Pour the mix in a mold
}
function cookAndLetChill() {
- Cook for 35 minutes
- Let chill
}
pourIngredients()
mixAndTransferToMold()
cookAndLetChill()
Как вы можете видеть, благодаря реализации функций, мы можем просто прочитать три вызова функций в конце файла и понять, что делает наша программа.
Такое упрощение и абстрактное представление является одним из преимуществ процедурного программирования. Однако внутри функций находится все тот же императивный код.
Функциональное программирование
Функциональное программирование продвигает концепцию создания функций немного дальше.
В функциональном программировании функции рассматриваются как «полноправные граждане». Это означает, что их можно присваивать переменным, передавать в качестве аргумента и возвращать в качестве результата других функций.
Еще одна ключевая концепция – это идея чистых функций. Чистая функций – это функция, которая, чтобы получить результат, полагается только на свои входные данные. И при одних и тех же входных данных всегда будет один и тот же результат. Кроме того, эти функции не имеют никаких побочных эффектов (то есть не вносят никаких изменений вне контекста функции).
С учетом всех этих концепций, функциональное программирование призывает писать программы с помощью функций. Оно также поддерживает идею о том, что модульность кода и отсутствие побочных эффектов облегчают определение и разделение обязанностей внутри кодовой базы. Таким образом, это облегчает сопровождение кода.
Вернемся к примеру с фильтрацией массива. В императивной парадигме мы можем использовать внешнюю переменную для хранения результата функции, что по сути может считаться побочным эффектом.
const nums = [1,4,3,6,7,8,9,2]
const result = [] // External variable
for (let i = 0; i < nums.length; i++) {
if (nums[i] > 5) result.push(nums[i])
}
console.log(result) // Output: [ 6, 7, 8, 9 ]
Для того, чтобы преобразовать это в функциональное программирование, мы можем сделать следующее:
const nums = [1,4,3,6,7,8,9,2]
function filterNums() {
const result = [] // Internal variable
for (let i = 0; i < nums.length; i++) {
if (nums[i] > 5) result.push(nums[i])
}
return result
}
console.log(filterNums()) // Output: [ 6, 7, 8, 9 ]
Это практически тот же самый код, но мы проворачиваем все итерации внутри функции, в которой мы также сохраняем и массив результатов. Таким образом, мы можем гарантировать, что функция не будет ничего менять за своими пределами. Она создает переменную только для обработки своей собственной информации, и после завершения своей работы удаляет ее.
Декларативное программирование
Декларативное программирование скрывает всю сложность и приближает языки программирования к человеческому языку и мышлению. Это абсолютная противоположность императивному программированию, хотя бы потому что программист дает инструкции не о том, как компьютеру следует решать задачу, а о том, какой требуется результат.
Будет намного понятнее, если мы приведем пример. Воспользуемся примером с фильтрацией массива. Декларативный подход здесь будет выглядеть следующим образом:
const nums = [1,4,3,6,7,8,9,2]
console.log(nums.filter(num => num > 5)) // Output: [ 6, 7, 8, 9 ]
Обратите внимание, что, используя функцию фильтрации filter, мы явно не указываем компьютеру перебирать массив или сохранять значения в отдельном массиве. Мы просто говорим о том, что мы хотим («filter») и условие, которое необходимо выполнить («num > 5»).
Что хорошего в таком подходе? Его легче читать и понимать, и зачастую он более емкий в записи. Хорошими примерами декларативного кода являются функции filter, map, reduce и sort в JavaScript.
Еще один хороший пример – современные фреймворки/библиотеки JS, такие как React. Посмотрите, например, на этот код:
<button onClick={() => console.log('You clicked me!')}>Click me</button>
Здесь у нас есть кнопка (button) с приемником событий, который запускает функцию console.log при нажатии кнопки.
Синтаксис JSX (то, что использует React) совмещает HTML и JS. Это упрощает и ускоряет написание приложений. Но это не то, что браузеры читают и выполняют. Код React позже преобразуются в обычный HTML и JS, а вот это уже то, с чем работают браузеры.
JSX является декларативным, поскольку его цель заключается в том, чтобы предоставить разработчикам более удобный и эффективный интерфейс для работы.
Здесь также важно отметить, что в декларативном программировании компьютер все равно обрабатывает информацию как императивный код.
Если снова вернуться к примеру с массивом, то компьютер по-прежнему выполняет итерацию по массиву, как в цикле for, но нам, как программистам, не нужно писать это напрямую. Декларативное программирование скрывает всю сложность от программиста.
Объектно-ориентированное программирование
Одной из самых популярных парадигм программирование является объектно-ориентированное программирование (ООП).
Основная концепция ООП заключается в разделении понятий на сущности, которые описываются как некие объекты. Каждая сущность группирует заданный набор информации (свойств) и действий (методов), которые может выполнять эта сущность.
ООП широко использует классы. Классы - это способ создания новых объектов с помощью макета или шаблона, который задает программист. Объекты, которые были созданы с помощью класса, называются экземплярами.
Вернемся к примеру с приготовлением пищи на псевдокоде. Предположим, что в нашей пекарне у нас есть главный повар (по имени Фрэнк) и помощник повара (по имени Энтони). У каждого их них есть определенные обязанности. Если бы мы использовали ООП, то наша программа бы выглядеть следующим образом:
// Create the two classes corresponding to each entity
class Cook {
constructor constructor (name) {
this.name = name
}
mixAndBake() {
- Mix the ingredients
- Pour the mix in a mold
- Cook for 35 minutes
}
}
class AssistantCook {
constructor (name) {
this.name = name
}
pourIngredients() {
- Pour flour in a bowl
- Pour a couple eggs in the same bowl
- Pour some milk in the same bowl
}
chillTheCake() {
- Let chill
}
}
// Instantiate an object from each class
const Frank = new Cook('Frank')
const Anthony = new AssistantCook('Anthony')
// Call the corresponding methods from each instance
Anthony.pourIngredients()
Frank.mixAndBake()
Anthony.chillTheCake()
Преимущество ООП заключается в том, что оно облегчает понимание программы за счет четкого разделения задач и обязанностей.
Итоги
Как мы увидели, парадигмы программирования – это различные способы решения задач программирования и организации нашего кода.
Одними из самых популярных и широко используемых на сегодняшний день парадигм являются императивная, процедурная, функциональная, декларативная и объектно-ориентированная. Знание о том, что они из себя представляют, полезно для общего развития, а также для лучшего понимания других тем, связанных с программированием.
Из предыдущих статей (тут и тут) мы узнали, что очень немногие механизмы, учитывают изменения в топологии. Большинство этих решений ориентированы на вычисления loop-free пути через очевидно стабильную сеть. Но что происходит при изменении топологии? Как сетевые устройства создают таблицы, необходимые для пересылки пакетов по loop-free путям в сети?
В этой серии статей мы рассмотрим очередную подзадачу этой всеобъемлющей проблемы и ответим на вопрос: Как плоскости управления обнаруживают изменения в сети и реагируют на них?
На этот вопрос мы ответим, рассмотрев две составляющие процесса конвергенции в плоскости управления. Процесс конвергенции в сети может быть описан в четыре этапа. Рисунок 1 используется для справки при описании этих четырех стадий. Как только связь [C,E] выходит из строя, должны произойти четыре этапа: обнаружение, распространение, вычисление и установка.
Обнаружение изменения: будь то включение нового устройства или линии связи, или удаление устройства или линии связи, независимо от причины, изменение должно быть обнаружено любыми подключенными устройствами. На рисунке 1 устройства C и E должны обнаруживать отказ канала [C, E]; когда линия восстанавливается, они также должны обнаружить включение этой (очевидно новой) линии связи в топологию.
Распространение информации об изменении: каждое устройство, участвующее в плоскости управления, должно каким-то образом узнавать об изменении топологии. На рисунке 1 устройства A, B и D должны каким-то образом уведомляться о сбое канала [C, E]; когда линия будет восстановлена, они должны быть снова уведомлены о включении этой (очевидно новой) линии связи в топологию.
Вычисление нового пути к пункту назначения без петель: на рисунке 1 B и C должны вычислить некоторый альтернативный путь, чтобы достичь пунктов назначения за пределы E (или, возможно, непосредственно самого E).
Установка новой информации о пересылке в соответствующие локальные таблицы: На рисунке 1 B и C должны установить вновь вычисленные loop-free пути к пунктам назначения за пределами E в свои локальные таблицы пересылки, чтобы трафик мог коммутироваться по новому пути.
Далее мы сосредоточимся на первых двух из четырех шагов, описанных в предыдущем списке, размышляя в начале об обнаружении изменений топологии. Будут рассмотрены некоторые примеры протоколов, специализирующихся на обнаружении изменений топологии. Распределение топологии и информации о достижимости будет рассмотрена в конце этой серии статей. Поскольку эта проблема, по сути, является проблемой распределенной базы данных, она будет решаться с этой точки зрения.
Обнаружение изменений топологии
Первым шагом в реакции на изменение топологии сети является обнаружение изменения. Вернемся к рисунку 1. Каким образом два устройства, подключенные к каналу, C и E, обнаруживают сбой канала? Решение этой проблемы не так просто, как может показаться на первый взгляд, по двум причинам: информационная перегрузка и ложные срабатывания.
Информационная перегрузка возникает, когда плоскость управления получает так много информации, что просто не может распространять информацию об изменениях топологии и/или вычислять и устанавливать альтернативные пути в соответствующие таблицы на каждом устройстве достаточно быстро, чтобы поддерживать согласованное состояние сети. В случае быстрых, постоянно происходящих изменений, таких как отключение связи и подключение каждые несколько миллисекунд, плоскость управления может быть перегружена информацией, в результате чего сама плоскость управления потребляет достаточно сетевых ресурсов, чтобы вызвать сбой сети. Также возможно, что серия отказов вызовет петлю положительной обратной связи, и в этом случае плоскость управления “сворачивается” сама по себе, либо реагируя очень медленно, либо вообще отказывая. Решение проблемы информационной перегрузки состоит в том, чтобы скрыть истинное состояние топологии от плоскости управления до тех пор, пока скорость изменения не окажется в пределах, которые может поддерживать плоскость управления.
Ложные срабатывания - это проблема второго типа. Если канал отбрасывает один пакет из каждых 100, и каждый раз отбрасывается единственный пакет, который оказывается пакетом плоскости управления, используемым для отслеживания состояния канала, будет казаться, что канал выходит из строя и довольно часто возобновляет работу - даже если другой трафик перенаправляется по каналу без проблем.
Существует два широких класса решений проблемы обнаружения событий:
Реализации могут периодически отправлять пакеты для определения состояния канала, устройства или системы. Это опрос (Polling).
Реализации могут вызвать реакцию на изменение состояния канала или устройства в некотором физическом или логическом состоянии внутри системы. Это обусловлено событиями.
Как всегда, есть разные компромиссы с этими двумя решениями и подкатегории каждого из них.
Опрос (Polling) для обнаружения сбоев.
Опрос может выполняться удаленно или вне диапазона, или локально, или в группе. Рисунок 2 демонстрирует это.
На рисунке 2 A и B периодически отправляют приветствие или какой-либо другой пакет опроса по тому же каналу, через который они подключены, и по тому же каналу, по которому они пересылают трафик. Это внутриполосный опрос, который имеет преимущество отслеживания состояния канала, по которому пересылается трафик, передается информация о доступности и т. д. С другой стороны, D запрашивает у A и B некоторую информацию о состоянии канала [A, B] из другого места в сети. Например, D может периодически проверять состояние двух интерфейсов на канале [A, B] или, возможно, периодически отправлять пакет по пути [C, A, B, C] и т. д. Преимущество заключается в том, что информация о состоянии большого количества каналов может быть централизована, что упрощает управление сетью и устранение неполадок. Оба типа опроса часто используются в реальных сетевых развертываниях.
Для работы механизмов опроса часто используются два отдельных таймера:
Таймер для определения частоты передачи опроса. Он часто называется интервалом опроса в случае внеполосного опроса и часто называется таймером приветствия в случае внутриполосного опроса.
Таймер, чтобы определить, как долго ждать, прежде чем объявить связь или устройство отключенным, или включить сигнал тревоги. Это часто называют мертвым интервалом или мертвым таймером в случае внутриполосного опроса.
Цели внутриполосного и внеполосного опроса часто различаются. Внеполосный опрос для обнаружения изменений в состоянии сети часто (но не всегда - особенно в случае централизованной плоскости управления) используется для мониторинга состояния сети и позволяет централизованно реагировать на изменения в состоянии. Внутриполосный опрос наиболее часто используется (как и следовало ожидать) для локального обнаружения изменений состояния, чтобы управлять реакцией распределенных плоскостей управления.
Обнаружение сбоев на основе событий
Обнаружение сбоев на основе событий основывается на некотором локальном, измеримом событии для определения состояния конкретного канала или устройства. Рисунок 3 демонстрирует это.
На рисунке 3, который показывает одну из возможных реализаций элементов архитектуры между физическим интерфейсом и протоколом маршрутизации, есть четыре шага:
Связь между двумя микросхемами физического интерфейса (phy), расположенными на обоих концах связи, не работает. Микросхемы физического интерфейса обычно являются оптическими для электрических передач обслуживания. Большинство микросхем физического интерфейса также выполняют некоторый уровень декодирования входящей информации, преобразуя отдельные биты в сети в пакеты (десериализация) и пакеты в биты (сериализация). Информация кодируется физическим интерфейсом на носителе, который предоставляется двумя физическими микросхемами, подключенными к физическому носителю. Если канал не работает или один из двух интерфейсов отключен по какой-либо причине, микросхема физического интерфейса на другом конце канала увидит падение несущей почти в реальном времени - обычно в зависимости от скорости света и длины физического носителя. Это состояние называется потерей носителя.
Микросхема физического интерфейса при обнаружении потери несущей отправляет уведомление в таблицу маршрутизации (RIB) на локальном устройстве. Это уведомление обычно запускается как прерывание, которое затем транслируется в некоторую форму вызова интерфейса прикладного программирования (API) в код RIB, что приводит к тому, что маршруты, доступные через интерфейс, и любая информация о следующем переходе через интерфейс помечаются как устаревшие или удаляются из таблицы маршрутизации. Этот сигнал может или не может проходить через базу пересылаемой информации (FIB) по пути, в зависимости от реализации.
RIB будет уведомлять протокол маршрутизации о маршрутах, которые он только что удалил из локальной таблицы, на основе события отключения интерфейса.
Протокол маршрутизации затем может удалить любых соседей, доступных через указанные интерфейсы (или, скорее, через подключенные маршруты).
На рисунке 3 нет места, в котором бы присутствовал периодический процесс, проверяющий состояние чего-либо, а также не было бы пакетов, перемещающихся по сети. Весь процесс основан на том, что микросхема физического интерфейса теряет носитель на подключенной среде, следовательно, этот процесс управляется событиями.
Часто бывает, что состояние, управляемое событиями, и статус опроса совмещаются. Например, на рисунке 3, если бы станция управления периодически опрашивала статус интерфейса в локальном RIB, процесс от набора микросхем физического интерфейса к RIB был бы управляемым событием, а процесс от RIB на станцию управления будет направлен опросом.
Сравнение обнаружения на основе событий и на основе опроса
Таблица 1 отображает преимущества и недостатки каждого механизма обнаружения событий.
Внеполосный опросВнутриполосный опросУправляемый событиямиРаспределение статусовСтатус управляется централизованной системой; централизованная система имеет более полное представление об общем состоянии сетиСтатус определяется локальными устройствами; для получения более широкой картины состояния всей сети требуется сбор информации с каждого отдельного сетевого устройстваСтатус определяется локальными устройствами; для получения более широкой картины состояния всей сети требуется сбор информации с каждого отдельного сетевого устройстваСвязь состояния пересылки со связью или состоянием устройстваСообщение о состоянии связи и / или устройства может быть ложным; не проверяет возможность пересылки напрямуюСостояние канала и/или устройства может быть напрямую связано с возможностью пересылки (исключение сбоев в механизме проверки состояния)Состояние канала и/или устройства может быть напрямую связано с возможностью пересылки (исключение сбоев в механизме проверки состояния)Скорость обнаруженияПеред объявлением канала или устройства должен пройти некоторый интервал ожиданияне удалось предотвратить ложные срабатывания; замедляет сообщение об изменениях в сетиПеред объявлением канала или устройства должен пройти некоторый интервал ожиданияне удалось предотвратить ложные срабатывания; замедляет сообщение об изменениях в сетиНекоторый таймер перед сообщением о сбоях может быть желательным, чтобы уменьшить сообщение о ложных срабатываниях, но этот таймер может быть очень коротким и подкрепляться двойной проверкой состояния самой системы; как правило, гораздо быстрее при сообщении об изменениях сетиМасштабированиеДолжен передавать периодические опросы, потребляя пропускную способность, память и циклы обработки; масштабируется в этих пределахДолжен передавать периодические опросы, потребляя пропускную способность, память и циклы обработки; масштабируется в этих пределахНебольшие объемы текущего локального состояния; имеет тенденцию масштабироваться лучше, чем механизмы опроса
Хотя может показаться, что обнаружение, управляемое событиями, всегда должно быть предпочтительным, есть некоторые конкретные ситуации, когда опрос может решить проблемы, которые не могут быть решены механизмами, управляемыми событиями. Например, одно из главных преимуществ систем, основанных на опросе, особенно при внутриполосном развертывании, заключается в том, чтобы «видеть» состояние невидимых блоков. Например, на рисунке 4 два маршрутизатора соединены через третье устройство, обозначенное на рисунке как ретранслятор.
На рисунке 4 устройство B представляет собой простой физический повторитель. Все, что он получает по каналу [A, B], он повторно передает, как и получил, по каналу [B, C]. На этом устройстве нет какой-либо плоскости управления (по крайней мере, о том, что известно A и C). Ни A, ни C не могут обнаружить это устройство, поскольку оно не изменяет сигнал каким-либо образом, который мог бы измерить A или C.
Что произойдет, если канал [A, B] выйдет из строя, если A и B используют управляемый событиями механизм для определения состояния канала? A потеряет несущую, конечно, потому что физический интерфейс в B больше не будет доступен. Однако C будет продолжать принимать несущую и, следовательно, вообще не обнаружит сбой соединения. Если A и C могут каким-то образом общаться с B, эту ситуацию можно разрешить. Например, если B отслеживает все запросы протокола разрешения адресов (ARP), которые он получает, он может, когда канал [A, B] разрывается, каким-то образом отправить «обратный ARP», уведомляющий B о том, что A больше недоступен. Другое решение, доступное в этой ситуации, - это своего рода опрос между A и C, который проверяет доступность по всему каналу, включая состояние B (даже если A и C не знают, что B существует).
С точки зрения сложности, управляемое событиями обнаружение увеличивает поверхности взаимодействия между системами в сети, в то время как опрос имеет тенденцию сохранять состояние внутри системы. На рисунке 3 должен быть какой-то интерфейс между чипсетом физического интерфейса, RIB и реализацией протокола маршрутизации. Каждый из этих интерфейсов представляет собой место, где информация, которая может быть лучше скрыта через абстракцию, передается между системами, и интерфейс, который должен поддерживаться и управляться. Опрос, с другой стороны, часто может проводиться в рамках одной системы, полностью игнорируя существующие механизмы и технологии.
Пример: обнаружение двунаправленной переадресации
В этом подразделе будет изучен пример протокола, разработанного специально для определения состояния канала в сети. Ни один из этих протоколов не является частью более крупной системы (например, протокола маршрутизации), а скорее взаимодействует с другими протоколами через программные интерфейсы и индикаторы состояния.
Обнаружение двунаправленной переадресации (Bidirectional Forwarding Detection - BFD) основано на одном наблюдении: на типичном сетевом устройстве работает множество плоскостей управления, каждая со своим собственным механизмом обнаружения сбоев. Было бы более эффективно использовать один общий механизм обнаружения для всех различных плоскостей управления. В большинстве приложений BFD не заменяет существующие протоколы приветствия, используемые в каждой плоскости управления, а скорее дополняет их. Рисунок 5 демонстрирует это.
В модели BFD, скорее всего, будет по крайней мере два различных процесса опроса, работающих по одному и тому же логическому каналу (их может быть больше, если есть логические каналы, наложенные поверх других логических каналов, поскольку BFD также может использоваться в различных технологиях сетевой виртуализации). Опрос плоскости управления будет использовать приветствия (hellos) для обнаружения соседних устройств, выполняющих один и тот же процесс плоскости управления, для обмена возможностями, определения максимального блока передачи (MTU) и, наконец, для того, чтобы убедиться, что процесс плоскости управления на соседнем устройстве все еще работает. Эти приветствия проходят через соединение плоскости управления на рисунке 5, которое можно рассматривать как своего рода «виртуальный канал», проходящий через физический канал.
Опрос BFD будет выполняться под соединением уровня управления, как показано на рисунке, проверяя работу физического соединения и плоскостей пересылки (переадресации) на двух подключенных устройствах. Этот двухуровневый подход позволяет BFD работать намного быстрее, даже в качестве механизма опроса, чем любой механизм обнаружения на основе протокола маршрутизации.
BFD может работать в четырех различных режимах:
Асинхронный режим: в этом режиме BFD действует как облегченный протокол приветствия. Процесс BFD в A, потенциально работающий в распределенном процессе (или даже в специализированной интегральной схеме [ASIC]), отправляет пакеты приветствия в C. Процесс BFD в C подтверждает эти пакеты приветствия. Это довольно традиционное использование опроса через hellos.
Асинхронный режим с эхом: в этом режиме процесс BFD в A будет отправлять пакеты приветствия в C, поэтому пакеты приветствия будут обрабатываться только через путь пересылки, что позволяет опрашивать только путь пересылки. Для этого A отправляет пакеты приветствия в C, сформированные таким образом, что они будут переадресованы обратно в A. Например, A может отправить пакет C с собственным адресом A в качестве пункта назначения. C может забрать этот пакет и переслать его обратно к A. В этом режиме приветствия, передаваемые A, полностью отличаются от приветствий, передаваемых C. Подтверждения нет, только две системы посылают независимые приветствия, которые проверяют связь в двух направлениях с каждого конца.
Режим запроса: В этом режиме два одноранговых узла BFD соглашаются отправлять приветствия только тогда, когда подключение должно быть проверено, а не периодически. Это полезно в том случае, когда существует какой-то другой способ определения состояния канала—например, если канал [A, C] является каналом Ethernet, что означает, что обнаружение несущей доступен для обнаружения сбоя канала, - но этот альтернативный метод не обязательно является надежным для обеспечения точного состояния соединения во всех ситуациях. Например, в случае «коммутатора посередине», где B отключен от A, но не C, C может послать BFD привет, отметив любую проблему с подключением, чтобы убедиться, что его соединение с A все еще есть. В режиме запроса некоторые события, такие как потерянный пакет, могут вызвать локальный процесс для запуска события обнаружения BFD.
Режим запроса с эхом: этот режим похож на режим запроса - обычные приветствия не передаются между двумя устройствами, на которых работает BFD. Когда пакет передается, он отправляется таким образом, чтобы другое устройство переадресовало пакет приветствия обратно отправителю. Это снижает нагрузку на процессор на обоих устройствах, позволяя использовать гораздо более быстрые таймеры для приветствий BFD.
Независимо от режима работы, BFD вычисляет различные таймеры опроса (hello) и обнаружения (dead) отдельно по каналу связи. Лучший способ объяснить этот процесс-на примере. Предположим, что A отправляет управляющий пакет BFD с предлагаемым интервалом опроса 500 мс, а C отправляет управляющий пакет BFD с предлагаемым интервалом опроса 700 мс. Для связи выбирается большее число или, скорее, более медленный интервал опроса. Объясняется это тем, что более медленная система должна быть в состоянии идти в ногу с интервалом опроса, чтобы предотвратить ложные срабатывания.
Частота опроса изменяется при фактическом использовании, чтобы предотвратить синхронизацию пакетов приветствия в нескольких системах на одном и том же проводе. Если было четыре или пять систем, развертывающих Border Gateway Protocol (BGP) на одном канале множественного доступа, и каждая система устанавливает свой таймер для отправки следующего пакета приветствия на основе получения последнего пакета, все пять систем могут синхронизировать их передачу приветствия, чтобы все приветствия по сети передавались в один и тот же момент. Поскольку BFD обычно работает с таймерами длиной менее одной секунды, это может привести к тому, что устройство будет получать приветствия от нескольких устройств одновременно и не сможет обрабатывать их достаточно быстро, чтобы предотвратить ложное срабатывание.
Конкретная используемая модификация заключается в джиттере пакетов. Каждый передатчик должен взять базовый таймер опроса и вычесть некоторое случайное количество времени, которое составляет от 0% до 25% от таймера опроса. Например, если таймер опроса составляет 700 мсек, как в приведенном примере, A и C будут передавать каждый пакет приветствия примерно между 562 и 750 мсек после передачи последнего приветствия.
Последний момент, который следует учитывать, - это количество времени, в течение которого A и C будут ждать перед объявлением соединения (или соседа) отключенным. В BFD каждое устройство может вычислить свой собственный таймер отключения, обычно выраженный как кратное таймеру опроса. Например, A может решить считать канал (или C) отключенным после пропуска двух приветствий BFD, в то время как C может решить дождаться пропуска трех приветствий BFD.
В сегодняшней статье рассмотрим один из самых важных модулей Asterisk, который является необходимым инструментом в решении проблем со звонками (траблшутинга), статистики и отчётности. Речь пойдёт о модуле CDR Reports. Все примеры, традиционно, будем приводить на нашем FreePBX 13
/p>
CDR (Call Detailed Record) – это подробная запись об акте коммутации (звонке), которые были проведены на телефонной станции. Такие записи есть практически у любой существующей цифровой АТС. Каждый производитель цифровой АТС предлагает свои сервисы для просмотра CDR. В Asterisk это модуль CDR Reports.
Модуль CDR Reports позволяет формировать мгновенные отчёты о телефонных звонках, которые так или иначе проходили через Вашу IP-АТС. Это могут быть как внутренние звонки между сотрудниками компании, так и звонки из/во “внешний мир", Asterisk записывает всё. Можно посмотреть, как полную историю звонков, так и создать уникальный отчёт, отфильтровав записи по дате, временным интервалам, только исходящим звонкам, только по определенным номерам CID и так далее. Звонки, которые появятся в сформированном отчёте, можно прослушать прямо из модуля. Важно отметить, что модуль CDR Reports требует, чтобы CDR – записи хранились в базе данных.
О том, как Asterisk записывает детализирует телефонные события, вы можете прочитать в статье про cистему CEL (Channel Event Logging)
Для формирования вышеупомянутых отчётов, модуль CDR Reports имеет интерфейс. Нужно отметить, что неопытному пользователю может быть трудно работать с интерфейсом, поскольку он имеет множество опций, с которыми не все знакомы. Однако, напротив каждой опции предусмотрены подсказки, подробно описывающие для чего они нужны.
Рассмотрим интерфейс на примере FreePBX 13. Для того, чтобы в него попасть, с главной страницы переходим по следующему пути Reports - > CDR Reports, как показано на рисунке.
Перед нами открывается интерфейс модуля CDR Reports с множеством фильтров
Как видно, благодаря имеющимся фильтрам можно создавать самые разные отчёты. Коротко рассмотрим каждый фильтр:
Call Date – Дата звонка. Справа можно выбрать временной промежуток, который нас интересует
CallerID Number – Номер звонящего. Выводит все записи по определенному интересующему номеру телефона. Можно ввести множество номеров, разделяя их запятыми. Справа можно выбрать условия совпадения – “Начинается с", “Содержит", “Заканчивается на" и “Совпадает точно" данные условия можно применить и для остальных фильтров
CallerID Name – Имя звонящего
Outbound CallerID Number – Номер, с которого звонят, при исходящем звонке
DID – Искать по набранному номеру. Это удобно, когда в компании несколько входящих линий
Destination –Искать по номеру назначения. Например, когда звонок переведен на внутреннего сотрудника или звонок попал на Ring группу
Destination CallerID Name – Искать по имени, присвоенного номеру назначения
Userfield – Искать по полю Userfield, если оно включено на Extension’е
Account Code – Искать по Аккаунт коду
Duration – Продолжительность звонка. Справа можно выбрать интервал в секундах
Disposition – Искать по характеру обработки вызова. Например: ANSWERED, BUSY, NO ANSWER. Позволяет найти не отвеченные звонки, звонки которые были приняты, звонки, которые не были приняты по причине занятости абонента
Также записи можно сгруппировать по различным параметрам при помощи опции Group By
Как только все нужные фильтры заполнены интересующими входными данными, необходимо нажать клавишу Search, чтобы сформировался отчёт
Интерфейс статистики Merion Metrics
Как видите, стандартный модуль CDR Report содержит очень много различных фильтров и параметров, которые, зачастую, просто не нужны рядовому пользователю. Именно поэтому, мы создали свой собственный интерфейс построения отчётов для Asterisk, интуитивно понятный и упрощенный. Наша разработка обладает не только базовым функционалом модуля CDR Report, но также позволяет формировать визуализированные отчёты и диаграммы.
Посмотрите видео о том, как много радости приносит наш интерфейс статистики для IP - АТС Asterisk:
Интерфейс можно попробовать бесплатно, пройдя по ссылке -