По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Перед тем как начать чтение этой статьи, советуем ознакомиться с материалом про расчет пути по алгоритму Bellman - ford. Алгоритм диффузного обновления (Diffusing Update Algorithm -DUAL) - один из двух обсуждаемых здесь алгоритмов, изначально предназначенных для реализации в распределенной сети. Он уникален тем, что также удаляет информацию о достижимости и топологии, содержащуюся в конечном автомате алгоритма. Другие обсуждаемые здесь алгоритмы оставляют удаление информации на усмотрение реализации протокола, а не рассматривают этот аспект работы алгоритма внутри самого алгоритма. К 1993 году Bellman-Ford и Dijkstra были реализованы как распределенные алгоритмы в нескольких протоколах маршрутизации. Опыт, полученный в результате этих ранних реализаций и развертываний, привел ко "второй волне" исследований и размышлений о проблеме маршрутизации в сетях с коммутацией пакетов, что привело к появлению вектора пути и DUAL. Поскольку DUAL разработан как распределенный алгоритм, лучше всего описать его работу в сети. Для этой цели используются рисунки 8 и 9. Чтобы объяснить DUAL, в этом примере будет прослеживаться поток A, изучающего три пункта назначения, а затем обрабатываются изменения в состоянии доступности для этих же пунктов назначения. В первом примере будет рассмотрен случай, когда есть альтернативный путь, но нет downstream neighbor, второй рассмотрит случай, когда есть альтернативный путь и downstream neighbor. На рисунке 8 изучение D с точки зрения A: A узнает два пути к D: Через H стоимостью 3. Через C стоимостью 4. A не узнает путь через B, потому что B использует A в качестве своего преемника: A - лучший путь B для достижения D. Поскольку B использует путь через A для достижения D (пункта назначения), он не будет анонсировать маршрут, который он знает о D (через C) к A. B выполнит split horizon своего объявления D на A, чтобы предотвратить образование возможных петель пересылки. A сравнивает доступные пути и выбирает кратчайший путь без петель: Путь через H помечен как преемник. Возможное расстояние устанавливается равным стоимости кратчайшего пути, равной 3. A проверяет оставшиеся пути, чтобы определить, являются ли какие-либо из них downstream neighbors: Стоимость C составляет 3. A знает это, потому что C объявляет маршрут к D со своей локальной метрикой, равной 3. A сохраняет локальную метрику C в своей таблице топологии. Следовательно, A знает локальную стоимость в C и локальную стоимость в A. 3 (стоимость в C) = 3 (стоимость в A), поэтому этот маршрут может быть петлей, следовательно, C не удовлетворяет условию выполнимости. C не помечен как downstream neighbors. Downstream neighbors в DUAL называются возможными преемниками. Предположим, что канал [A, H] не работает. DUAL не полагается на периодические обновления, поэтому A не может просто ждать другого обновления с достоверной информацией. Скорее A должен активно следовать альтернативному пути. Таким образом, это диффузный процесс обнаружения альтернативного пути. Если канал [A, H] не работает, учитывая только D: A проверяет свою локальную таблицу на предмет возможных преемников (Downstream neighbors). Возможных преемников нет, поэтому A должен найти альтернативный путь без петель к D (если он существует). A отправляет запрос каждому соседу, чтобы определить, есть ли какой-либо альтернативный путь без петель к D. В C: Преемником C является E (не A, от которого он получил запрос). Стоимость E ниже, чем стоимость A для D. Следовательно, путь C не является петлей. C отвечает со своей текущей метрикой 3 на A. В B: А - нынешний преемник Б. Посредством запроса B теперь обнаруживает, что его лучший путь к D потерпел неудачу, и он также должен найти альтернативный путь. Обработка B здесь не расписывается, а предоставляется выполнить самостоятельно. B отвечает A, что у него нет альтернативного пути (отвечает бесконечной метрикой). A получает эти ответы: Путь через C - единственный доступный, его стоимость 4. A отмечает путь через C как его преемника. Других путей к D нет. Следовательно, нет подходящего преемника (downstream neighbor). На рисунке 9 пункт назначения (D) был перемещен с H на E. Это будет использоваться во втором примере. В этом примере есть возможный преемник (downstream neighbor). Изучение D с точки зрения A: A узнает два пути к D: Через H стоимостью 4. Через C стоимостью 3. A не узнает никакого пути через B: У B есть два пути к D. Через C и A стоимостью 4. В этом случае B использует как A, так и C. B выполнит split horizon свого объявления D на A, потому что A помечен как преемник. A сравнивает доступные пути и выбирает кратчайший путь без петель: Путь через C отмечен как преемник. Возможное расстояние устанавливается равным стоимости кратчайшего пути, равной 3. A проверяет оставшиеся пути, чтобы определить, являются ли какие-либо из них downstream neighbors: Стоимость H составляет 2. 2 (стоимость в H) = 3 (стоимость в A), поэтому этот маршрут не может быть петлей. Следовательно, H удовлетворяет условию выполнимости. H отмечен как возможный преемник (downstream neighbors). Если канал [A, C] не работает, просто рассматривая A: A проверит свою таблицу локальной топологии на предмет возможного преемника. Возможный преемник существует через H. A переключает свою локальную таблицу на H как лучший путь. Распространяющееся обновление не запускалось, поэтому пути не были проверены или пересчитано. Следовательно, допустимое расстояние изменить нельзя. Он остается на 3. A отправляет обновление своим соседям, отмечая, что его стоимость достижения D изменилась с 3 до 4. Как вы можете видеть, обработка, когда существует возможный преемник, намного быстрее и проще, чем без него. В сетях, где был развернут протокол маршрутизации с использованием DUAL (в частности, EIGRP), одной из основных целей проектирования будет ограничение объема любых запросов, генерируемых в случае отсутствия возможного преемника. Область запроса является основным определяющим фактором того, как быстро завершается двойной алгоритм и, следовательно, как быстро сходится сеть. На рисунке 10 показан базовый законченный автомат DUAL. Вещи, входящие в route gets worse (ухудшение маршрута), могут представлять собой: Отказ подключенного канала или соседа Получение обновления для маршрута с более высокой метрикой Получение запроса от текущего преемника Получение нового маршрута от соседа Обнаружен новый сосед, а также маршруты, по которым он может добраться Получение всех запросов, отправленных соседям, когда маршрут ухудшается
img
Сегодня хотим предложить крутой функционал, который тебе захочется установить на своей IP – АТС Asterisk прямо сейчас! Речь пойдет про отправку записи разговора на адрес электронной почты со всеми причитающимися метаданными звонка. Работает это примерно вот так: ваш сотрудник поговорил по телефону, положил трубку, после чего, ответственному по электронной почте приходит письмо с записью разговора, датой и временем звонка, а также номерами А и Б. Настроить эту «фичу» очень легко. Приступаем к настройке. Bash скрипт для Asterisk Сам по себе скрипт написан на bash. Скрипт будет инициироваться сразу после окончания звонка и в него будут переданы нужные для работы переменные. Но об этом чуть позже: #!/bin/bash dt=$(date '+%m/%d/%Y %r'); echo -e "Привет! Появилась новая запись разговоров на нашем сервере Asterisk Звонок был совершен $dt Нам позвонил этот номер - $5 Вызов принял - $7 Запись разговора во вложении " | mail -a /var/spool/asterisk/monitor/$1/$2/$3/$6 -s "Новая запись разговоров" info@merionet.ru Пробежимся по переменным, которые будут относится к звонку и будут передаваться (все кроме $dt) с Asterisk: $1 - год звонка; $2 - месяц звонка; $3 - день звонка; $4 - дата и время в формате строки; $5 - источник звонка (звонящий); $6 - имя файла аудио – записи разговора; $7 - куда был совершен вызов; $dt - генерируем дату звонка; Переходим в консоль сервера Asterisk. Первым делом создаем файл с расширением .sh в него мы поместим наш скрипт: touch /var/lib/asterisk/bin/rectoemail.sh Даем файлу нужные права и разрешения: chown asterisk:asterisk rectoemail.sh chmod 774 rectoemail.sh Теперь открываем сам файл скрипта для редактирования: vim /var/lib/asterisk/bin/rectoemail.sh И добавляем скрипт в файл. Для того, чтобы сделать это, скопируйте скрипт из статьи. В режиме редактирования через vim нажмите «o» на клавиатуре, затем нажмите правую кнопку мыши – скрипт будет добавлен в файл. После этого, нажмите Esc на клавиатуре и комбинацию :x! + Enter для сохранения изменений. Готово. Доработка в FreePBX Теперь нужно поставить наш скрипт на автоматический запуск. Переходим в раздел Settings → Advanced Settings. Убеждаемся, что параметры Display Readonly Settings и Override Readonly Settings установлены в значение Yes. Теперь находим параметр Post Call Recording Script и добавляем в его поле следующую строчку: bash /var/lib/asterisk/bin/rectoemail.sh ^{YEAR} ^{MONTH} ^{DAY} ^{TIMESTR} ^{FROMEXTEN} ^{CALLFILENAME}.^{MIXMON_FORMAT} ^{ARG3} Готово. Сохраняем настройки и переходим к тестам:
img
Firebase - это платформа для разработки приложений, запущенная в 2012 году и двумя годами позже приобретенная Google. Изначально Firebase задумывалась как база данных для приложений реального времени, но Google увидел ее потенциал и решил добавить к ней дополнительные сервисы. В настоящее время Firebase представляет собой систему BaaS (Backend as as Service) для упрощения создания веб-приложений и мобильных приложений с 18 службами. Среди компаний, использующих услуги BaaS Firebase, - Accenture, Alibaba Travels, Stack, Twitch и Instacart, а также более 2300 других. Преимущества использования Firebase Первой из услуг, предлагаемых Firebase, была база данных в реальном времени, и она остается одной из самых привлекательных. Real-time базы данных Firebase размещаются в облаке, хранят данные в формате JSON и синхронизируются в реальном времени с каждым подключенным к ним клиентом. Независимо от того, используете ли вы iOS SDK, Android SDK или JavaScript SDK, все приложения, подключенные к Realtime базе данных Firebase, совместно используют один экземпляр базы данных, всегда работают с последними данными. Cloud Firestore - еще один интересный сервис Firebase. Это NoSQL база данных документов, предназначенная для облегчения хранения, синхронизации и выполнения запросов для мобильных и веб-приложений в глобальном масштабе. Создание иерархий для хранения связанных данных и запросов для получения данных позволяет полностью реализовать потенциал Cloud Firestore. В свою очередь, запросы масштабируются в зависимости от размера результатов, а не от размера набора данных. Это позволяет приложениям масштабироваться с самого начала, не дожидаясь момента, когда запрашиваемые ресурсы превысят имеющиеся. В дополнение к вышеупомянутым службам баз данных Firebase также предлагает услуги хостинга, хранилища файлов, функции (в стиле AWS Lambda) и многое другое. Создание API API-интерфейсы - это способ предоставления услуг для использования вашими собственными или сторонними приложениями. Firebase позволяет предоставлять настраиваемые службы, которые, в свою очередь, используют собственные службы Firebase, без необходимости настраивать серверную часть для этих служб. Вы можете, например, предложить доступ к базе данных Firebase в реальном времени для сторонних приложений для запроса информации, собираемой промышленными датчиками. Первым шагом в создании API в Firebase является доступ к консоли Firebase и добавление проекта, нажав «Добавить проект» (Add project) и присвоив название новому проекту. Google предоставит вам возможность включить Google Analytics для вашего нового проекта. Рекомендуется принять эту рекомендацию, так как вы получите такие преимущества, как A/B-тестирование и широкий спектр статистических отчетов относительно вашего API. После создания проекта вы сможете выбрать службы Firebase, которые будет использовать ваш API. Чтобы проиллюстрировать эту задачу, мы разберём, как использовать службу базы данных Firebase Realtime. Настройка базы данных реального времени в Firebase На панели навигации слева в разделе «Разработка» (Develop) щелкните «Realtime Database». Справа появится кнопка «Create Database». Нажмите на нее, чтобы создать свою первую базу данных в Firebase. Затем вам нужно будет выбрать один из нескольких вариантов географического местоположения для вашей новой базы данных. Выберите тот, который ближе всего к вашим пользователям. Это важный аспект для минимизации задержки вашего API, особенно для приложений реального времени. Следующим шагом является настройка основных правил безопасности для вашей базы данных. Вы можете выбрать заблокированный режим, а затем назначить права доступа по мере необходимости или выбрать тестовый режим, который разрешает все операции чтения и записи. Для начала, чтобы не усложнять свою жизнь настройками безопасности, можно выбрать тестовый режим. А правила безопасности можете настроить позже. Как только вы закончите настройку своей базы данных, соответствующий API также будет добавлен в разделе API and Services в консоли Google Cloud Platform. Программирование Firebase API На данный момент у вас уже есть основные элементы вашего проекта, настроенные в консоли Firebase. Следующим шагом будет написание кода API. Для этого вам нужно будет инициализировать хостинг и функции Firebase на вашем локальном компьютере. Вы можете установить firebase-tools с помощью npm: npm install -g firebase-tools Затем вы можете войти в firebase и инициализировать свой проект с помощью следующих команд: firebase login firebase init Отобразится экран приветствия, в котором Firebase укажет папку папке, в которой будет храниться ваш проект, и появится меню параметров. В этом меню выберите Functions and Hosting (опция «Хостинг» позволит вам иметь собственный URL-адрес для API). Затем выберите из списка приложение Firebase, которое вы создали ранее, после чего вы должны выбрать язык для использования. Для разработки веб-API вы можете выбрать JavaScript. Если вы будете использовать зависимости пакетов, установите их с помощью npm внутри папки функций. Затем вы можете начать писать код для своих функций. Не забудьте включить пакеты firebase-functions и firebase-admin наряду с другими пакетами, которые вам нужны: import * as functions from 'firebase-functions'; import * as admin from 'firebase-admin'; Чтобы использовать базу данных в реальном времени, вы должны указать ее URL при инициализации вашего JavaScript SDK. URL-адрес находится в разделе Realtime Database консоли Firebase. Вы можете узнать его по формату: https://<database-name>.<region>.firebasedatabase.app Вы можете использовать следующий фрагмент кода для инициализации вашего SDK, заменяя данные на свои: var config = { apiKey: "apiKey", authDomain: "projectId.firebaseapp.com", databaseURL: "https://databaseName.firebaseio.com", storageBucket: "bucket.appspot.com" }; firebase.initializeApp(config); var database = firebase.database(); После того, как написали код функции API, пора приступить к развертыванию. Но перед этим нужно будет внести некоторые изменения в firebase.json, добавив следующие строки, измененные в соответствии с конфигурацией нашего проекта: "rewrites": [ { "source": "/api/v1/**", "function": "webApi" } ] Следующий шаг - развертывание. В первый раз нужно выполнить полное развертывание, выполнив команду: firebase deploy При последующих развертываниях вы сможете развертывать только функции, используя параметр –only functions. После выполнения команды Firebase CLI в терминале отобразит URL-адреса HTTP эндпоинтов ваших функций, которые вы можете использовать для вызова ваших API-интерфейсов из веб-приложения. URL-адрес содержит идентификатор вашего проекта и регион для функции HTTP. Например, следующий URL-адрес можно использовать для вызова функции запроса элемента, передав его itemid = 1 в качестве параметра: https://us-central1-apiproject-8753c.cloudfunctions.net/itemQuery?itemid=1 Чтобы выполнить функцию, откройте URL-адрес с соответствующими параметрами в браузере. Обратите внимание, что для развертывания в производственной среде требуется подписка на план Firebase Blaze. Данный план снимает деньги по мере использования, о чем вы можете прочитать на странице цен на Firebase. Это услуга выставляет счет по факту использования, что означает, что вам выставляется счет за использование в конце каждого месяца. Если у вас нет подписки на Blaze, команда развертывания не отобразит URL-адрес для API. Вместо этого вы увидите сообщение, информирующее о том, что вы должны подписаться на план Blaze, если вы хотите выполнить развертывание в среде выполнения. В этом случае вы все равно можете использовать Firebase Local Emulation Suite для создания и тестирования приложений на локальном компьютере вместо их развертывания в производственной среде Firebase. Локальное тестирование полезно, чтобы избежать ненужных затрат во время разработки приложения, поскольку каждый запуск теста может приводить к расходам на вашем счете. Локальное тестирование и прототипирование Инструмент Local Emulator Suite предлагает интегрированный пользовательский интерфейс, который делает упрощает создание прототипов и тестирование ваших приложений на локальном компьютере. С помощью пользовательского интерфейса Emulator Suite вы можете тестировать проекты своей базы данных, рабочие процессы облачных функций, анализировать производительность серверных служб и оценивать изменения в правилах безопасности и пр. По сути, это безопасная песочница для проверки функциональности вашего API перед отправкой в производственную среду. Чтобы эмулировать свои функции или протестировать приложение локально, запустите эмуляторы firebase: start. Чтобы использовать эмулятор Firestore, на компьютере должна быть установлена Java. При вызове Firestore Emulator, команда вернет URL-адрес, который позволит вам открыть пользовательский интерфейс Emulator Suite в вашем браузере. По умолчанию этот URL-адрес будет localhost: 4000, но он может отличаться на каждой машине. Вы также получите полный URL-адрес своей функции HTTP. Этот URL будет выглядеть примерно так: http://localhost:5001/apiproject-8753c/us-central1/itemQuery Только он будет иметь имя вашего проекта, имя вашей функции, а также может иметь другой номер порта на вашем локальном компьютере. Чтобы протестировать функцию, скопируйте URL-адрес, возвращаемый эмулятором, добавив все необходимые параметры (например, ?itemid = 1), и откройте в новой вкладке браузера. Результаты выполнения API появятся в пользовательском интерфейсе Emulator Suite. На вкладке «Logs» вы увидите новые логи, указывающие, что функция itemQuery() была выполнена. Если ваша функция генерирует новые данные в базе данных Firestore, вы увидите их на вкладке Firestore. Расширение возможностей вашего API Если вы хотите, чтобы разрабатываемые вами API стали популярными, Firebase может помочь и с этим. Не только потому, что это позволяет вам быстрее создавать приложение, снимая много работы по настройке и запуску серверных сервисов, но также помогая вам в позиционировании вашего продукта. Как такое возможно? Просто потому, что приложения, связанные с Firebase, занимают более высокие позиции в поисковом рейтинге, чем другие приложения. Также примите во внимание API индексирования приложений Firebase. Этот инструмент улучшает поисковый рейтинг ссылок приложений и помогает пользователям находить желаемый контент. Он также помещает кнопку "Установить" после кнопки на главной странице вашего приложения, чтобы заинтересованные пользователи всего за один клик могли пользоваться вашим приложением. В заключение отметим, что Firebase не только предлагает услуги бэкэнда, которые значительно ускоряют разработку собственного API, но и помогает продвигать его и зарабатывать на этом деньги.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59