По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Первая часть тут.
В конце 1980—х в мире сетевой инженерии появилась новая тема для обсуждения-асинхронный режим передачи данных (ATM). Потребность в более скоростных схемах в сочетании с медленным развитием в коммутации пакетов персонально на основе их адресов назначения привела к толчку к новому виду передачи, который, в конечном счете, реконфигурировал бы весь набор (или стек, потому что каждый протокол образует слой поверх протокола ниже, как «слоёный пирог») протоколов, используемых в современных сетях. ATM объединил размер ячейки (или пакета) с фиксированной длиной коммутации каналов с заголовком из коммутации пакетов (хотя и значительно упрощенным), чтобы произвести «промежуточное» технологическое решение. Было два ключевых момента для ATM: label switching и fixed call sizes; рисунок 1 иллюстрирует первый вариант.
На рис. 1 G отправляет пакет, предназначенный для H. При получении этого пакета A проверяет локальную таблицу и обнаруживает, что следующий переход к H — это C. Локальная таблица A также указывает метку, показанную как L, а не «просто» информацию о том, куда переслать пакет. A вставляет эту метку в специальное поле в начале пакета и пересылает ее в C. Когда C получает пакет, ему не нужно читать адрес назначения в заголовке, скорее, он просто читает метку, которая является коротким полем фиксированной длины. Метка просматривается в локальной таблице, которая сообщает C переадресовать трафик в D для назначения H. Метка очень мала и поэтому легко обрабатывается для устройств пересылки, что делает переключение намного быстрее.
В некотором смысле метка также может «содержать» информацию для обработки пакета. Например, если на самом деле существует два потока трафика между G и H, каждому из них может быть назначена своя метка (или набор меток) через сеть. Пакеты, несущие одну метку, могут иметь приоритет над пакетами, несущими другую метку, поэтому сетевым устройствам не нужно просматривать какие-либо поля в заголовке, чтобы определить, как обрабатывать конкретный пакет.
Это можно рассматривать как компромисс между коммутацией пакетов и коммутацией каналов. В то время как каждый пакет все еще пересылается hop by hop, виртуальный канал также может быть определен путем метки через сеть. Второй момент заключался в том, что ATM также был основан на ячейке фиксированного размера: каждый пакет был ограничен 53 октетами информации. Ячейки фиксированного размера могут показаться незначительной проблемой, но пакеты фиксированного размера могут иметь огромное значение для производительности. Рисунок 2 иллюстрирует некоторые факторы, связанные с фиксированными размерами ячеек.
На рисунке 2 пакет 1 (A1) копируется из сети в память на сетевой карте или интерфейсе LC1; затем он проходит через внутреннюю структуру внутри B (между ячейками памяти) к LC2, и, наконец, возвращается в сеть на исходящем интерфейсе B. На такой диаграмме это может показаться тривиальным, но, пожалуй, наиболее важным фактором скорости, с которой устройство может переключать / обрабатывать пакеты, является время, необходимое для копирования пакета по любым внутренним путям между ячейками памяти. Процесс копирования информации из одного места в памяти в другое является одной из самых медленных операций, которые может выполнять устройство, особенно на старых процессорах. Создание одинакового пакета (фиксированный размер ячейки) позволило оптимизировать код во время процесса копирования, что значительно увеличило скорость переключения.
Путь пакета 2 через B еще хуже с точки зрения производительности; сначала он копируется из сети в локальную память. Когда порт назначения определяется путем поиска в локальной таблице пересылки, код, обрабатывающий пакет, понимает, что пакет должен быть фрагментирован, чтобы соответствовать наибольшему размеру пакета, разрешенному на исходящем канале [B,C]. Карта входящей линии, LC1, фрагментирует пакет на A1 и A2, создавая второй заголовок и корректируя любые значения в заголовке по мере необходимости. Пакет делится на два пакета, А1 и А2. Эти два пакета копируются в двух операциях через матрицу на исходящую сетевую карту LC2. Используя ячейки фиксированного размера, ATM избегает затрат на производительность фрагментации пакетов (в то время, когда предлагалась ATM), понесенных почти любой другой системой коммутации пакетов.
ATM, на самом деле, не начинался в ядре сети и не прокладывал свой путь к краю сети. А почему бы и нет? Первый ответ заключается в довольно странном выборе размера ячейки. Почему 53 октета? Ответ прост-и, возможно, немного поразителен. АТМ должна была заменить не только сети с коммутацией пакетов, но и тогдашнее поколение голосовых сетей, основанных на технологиях коммутации каналов. Объединяя эти две технологии, провайдеры могли бы предлагать оба вида услуг на одном наборе схем и устройств.
Какой объем информации или размер пакета идеально подходит для передачи голосового трафика? Около 48 октетов. Какой объем информации или размер пакета является минимумом, который имеет какой-либо смысл для передачи данных? Около 64 октетов. Пятьдесят три октета были выбраны в качестве компромисса между этими двумя размерами; это не было бы идеально для передачи голоса, так как 5 октетов каждой ячейки, несущей голос, были бы потрачены впустую. Это не было бы идеально для трафика данных, потому что самый распространенный размер пакета, 64 октета, должен был бы быть разделен на две ячейки для переноса через сеть ATM. Общим мнением во время проведения этих обсуждений было то, что протоколы передачи данных могли бы адаптироваться к немного меньшему размеру ячейки, что делает 53 октета оптимальным размером для поддержки широкого спектра трафика. Протоколы передачи данных, однако, не изменились. Для переноса 64-октетного блока данных одна ячейка будет содержать 53 октета, а вторая - 9 октетов с 42 октетами свободного пространства. Провайдеры обнаружили 50% или более доступной пропускной способности на каналах ATM использовались пустые ячейки, что фактически приводило к потере пропускной способности. Следовательно, поставщики данных прекратили развертывание ATM, поставщики голосовой связи так и не начали его развертывание, и ATM умер.
Что интересно, так это то, как наследие таких проектов, как ATM, живет в других протоколах и идеях. Концепция переключения меток была подхвачена Yakov Rekhter и другими инженерами и превращена в переключение меток. Это сохраняет многие фундаментальные преимущества быстрого поиска ATM на пути пересылки и объединения метаданных об обработке пакетов в саму метку. Коммутация по меткам в конечном итоге стала Multiprotocol Label Switching (MPLS), которая не только обеспечивает более быстрый поиск, но также стеки меток и виртуализацию. Таким образом, была взята и расширена основная идея, которая существенно повлияла на современные сетевые протоколы и конструкции.
Вторым наследием ATM является фиксированный размер ячейки. В течение многих лет доминирующий сетевой транспортный пакет, основанный на TCP и IP, позволял сетевым устройствам фрагментировать пакеты при их пересылке. Однако это хорошо известный способ снижения производительности сети. Бит «не фрагментировать» был добавлен в заголовок IP, сообщая сетевым устройствам о необходимости отбрасывать пакеты, а не фрагментировать их, и были предприняты серьезные усилия для обнаружения самого большого пакета, который может передаваться по сети между любой парой устройств. Новое поколение IP, названное IPv6, удалило фрагментацию сетевыми устройствами из спецификации протокола.
Третья часть тут.
Новый, и безусловно интересный модуль Calendar позволяет гибко управлять временной сегментацией вызова. Что это значит? Теперь маршрутизация вызова и привычные time – conditions и time – group, которые строго настраиваются через графический интерфейс FreePBX, могу быть сконфигурированы простой синхронизацией с календарем!
В статье расскажем о возможностях модуля и настройке интеграции с Google календарями.
Настройка с Google
Модуль уютно расположился в разделе Applications → Calendar.
Собственно, давайте попробуем прикрутить Google Calendar к FreePBX? Логинимся в наш календарь:
Слева, в разделе Мои календари выбираем нужный. Наводим на него курсор мыши и в разделе редактирования отмечаем Настройки и общий доступ. В разделе настроек листаем вниз и находим URL в опции Закрытый адрес в формате iCal:
Проще простого. А теперь прыгаем в настройку модуля Calendar и выбираем опцию Add Remote iCal Calendar. Указываем следующие опции:
Name - имя для календаря;
Description - описание для календаря;
Remote URL - ссылка на ical, о которой мы говорили ранее;
Synchronization Time - как часто синхронизировать календарь? Гиперактивность нашего эвент – менеджера навела на мысль сделать 10 минут;
Сохраняем.
Сохранил, что дальше?
А дальше все гораздо интереснее. Теперь можно настроить временную сегментацию с помощью календаря! Прыгаем в Applications и далее во вкладку Time Conditions:
Time Zone - временная зона для этого календаря;
Mode - в каком режиме работать этому временному условию: мы выбираем в режиме календаря;
Calendar - какой календарь использовать? В случае, если на время работы этого временного условия есть отметка в календаре, то временная кондиция отработает (по аналогии с Time Group);
Calendar Group - группа календарей. Работает так же по схеме сопоставления событий;
Круто, да? Но подождите удивляться. Календарь можно интегрировать с Follow Me! То есть менеджер автоматически по событию в календаре включать переадресацию на мобильный! Прыгаем в Applications → Extensoins и выбираем Follow Me:
Enable Calendar Matching - включаем режим календаря;
Calendar - какой календарь использовать? В случае, если на время работы этого временного условия есть отметка в календаре, то временная кондиция отработает (по аналогии с Time Group);
Calendar Group - группа календарей. Работает так же по схеме сопоставления событий;
Calendar Match Inverse - когда установлено в положение Yes, то Follow Me будет отрабатывать когда есть событие в календаре, а когда выставлено в положение No, то когда события нет;
Большинству из нас знакомо слово "сервер". Во многих организациях, таких как учебные заведения (школы, университеты), офисы и больницы, есть сервер, который обеспечивает бесперебойную работу сетевых устройств, в том числе и компьютеров. Но какое же реальное предназначение сервера?
"Сервер не работает", "не удается установить соединение с сервером" ... подобные сообщения стали обычным явлением в современном мире, зависящем от гаджетов. Но что такое сервер, на который ссылаются эти сообщения, и каково его место в сети или инфраструктуре организации? Ответ может быть один из двух:
Физический компьютер, задачей которого является предоставление услуг всем терминалам или компьютерам, подключенным к нему, например предоставление разрешений или выделение ресурсов.
Когда в клиент-серверной модели, сервер - это программное обеспечение или программа, работающая на одном или нескольких компьютерах, которая управляет ресурсами и службами сети, одновременно обрабатывая запросы от разных компьютеров на доступ к указанным ресурсам.
Особенности компьютерного сервера
Из приведенного выше определений сервера ясно, что это не обычный, повседневный компьютер и, следовательно, его аппаратное обеспечение должно соответствовать требованиям современных реалий:
Должно быть много оперативной памяти. Для высокоскоростной обработки различных запросов от разных компьютеров и выполнения операций, с высокой эффективностью, требуется много оперативной памяти.
Оптимальная скорость процессора. Её должно хватать для выполнения всех команд, запрашиваемых другими машинами, а также для многозадачности.
Жесткие диски должны быть большой емкости. Данные могут храниться на сервере в любой форме, и он должен быть способен хранить большие объемы данных.
Должна быть хорошая охлаждающая система, для поддержания стабильной температуры внутри системы. Из-за мощной аппаратной части сервер может перегреться и отключиться.
Эффективная операционная система. Операционная система сервера должна быть способна обрабатывать множество операций и должна быть стабильной. Linux является одной из наиболее предпочтительных ОС для серверов.
Отказоустойчивость, надежность сервера. Сервер не должен отказывать или выключаться из-за неисправного оборудования. Он должен быть надежным и безотказным. Для этого ему нужны надежные аппаратные части и компоненты, которые не выйдут из строя от чрезмерного использования.
Бесперебойное электроснабжение. Сервер обрабатывает важные данные в режиме реального времени. Работа сервера не должна прерываться даже при отключении основного источника электроэнергии. Поэтому ИБП должен быть настроен так, чтобы серверы продолжали работать даже при отключении основного источника питания.
Избыточность. Должен быть установлен дополнительный сервер, дополнительный жесткий диск или система хранения данных (СХД) для выполнения резервного копирования данных с основного сервера. Это делается для того, чтобы была возможность в любой момент восстановить данные.
Особенности компьютерного сервера
Сервер приложений (Application servers)
Сервер базы данных (Database server)
Файловый сервер (File server)
Сервер ftp (FTP servers)
Игровой сервер (Game server)
Почтовый сервер (Mail server)
Сетевой сервер (Network server)
Домашний сервер (Home server)
Факс-сервер (Fax server)
Сервер имен (Name server)
Сервер печати (Print server)
Прокси сервера (Proxy server)
Автономный сервер (Stand-alone server)
Виртуальный сервер (Virtual servers)
Звуковой сервер (Sound server)
Веб-сервер (Web server)
Серверы связи в реальном времени (серверы чата) (Real-time communication servers (chat servers)