Сочинение на тему Пригодность транспортных протоколов для времени отклика
- Опубликовано: 10.10.2020
- Предмет: Бизнес, Психология
- Темы: Промышленность, развитие, Развитие ребенка
Наша команда сотрудничает с отраслевым партнером по разработке и оптимизации системы Universal Radio Gateway (URGW). Эта система обеспечивает возможность интеграции радиостанций различных запатентованных аналоговых и цифровых радиосистем, таких как TETRA, TETRAPOL и т. Д., В более сложную инфраструктуру связи. Остальная часть этой инфраструктуры в основном основана на VoIP, мобильных сетях 3-4G и PSTN. Радиосистемы этого типа в основном используются армейскими, полицейскими, пожарными и аварийными службами. Помимо прочего, система URGW позволяет оператору-диспетчеру удаленно управлять радиостанцией и использовать ее как своего рода однолинейную магистраль от общей инфраструктуры VoIP-PSTN до проприетарной радиосети. Цель состоит в том, чтобы сохранить как можно больше возможностей радиосистемы и прозрачно преобразовать услуги в среду VoIP. Ожидается, что используемой радиостанции предоставлены некоторые более высокие права в радиосети (т. Е. Диспетчер радиогруппы), но во всех других отношениях она все еще ведет себя так же, как обычная радиостанция конечного пользователя без специального доступа к системе управления радиосетью. Таким образом, URGW получает доступ к услугам радиосети в основном путем эмуляции контроля живого пользователя подключенными станциями. Несмотря на то, что система URGW намного сложнее в ее реальной форме, ее можно упростить до трех основных модулей, для целей этой статьи см. Рисунок 1.
Высокоуровневая архитектура системы URGW
<Р> а. Пост диспетчера (DP) Пост диспетчера – это компьютерная станция, где живой человек управляет процессом связи и способствует плавному переходу от полнодуплексной среды PSTN / PLMN / VoIP к полудуплексной радиосвязи. Как только оператор выбирает удаленную станцию из списка, пост диспетчера соединяется с радиостанцией с помощью контроллера радиостанции и начинает использовать ее в цепи связи.
<Р> В. Арбитр Арбитр – это автоматическая бэкэнд-сущность, управляющая списками доступных радиостанций, их фактическим состоянием и рекламируемыми услугами. Если диспетчер хочет использовать определенную станцию, он спрашивает арбитра, и доступ предоставляется, если есть совпадение требуемых и предлагаемых услуг. Когда станция занята, она удаляется из списка доступных станций, и другие диспетчеры не могут получить к ней доступ. Процесс регистрации станции / диспетчера, а также настройка соединения основаны на протоколе SIP. Обычно арбитр представляет собой модуль более крупной системы связи, такой как обмен VoIP PBX.
<Р> С. Контроллер радиостанции (RSC) Контроллер радиостанции – это устройство, подключенное к физической радиостанции с помощью соответствующего интерфейса. Интерфейс сильно зависит от реальных возможностей станции. В самом примитивном случае это может быть только аналоговый аудиоканал с управлением клавишами, как если бы живой человек управлял станцией textove. Более сложные станции обеспечат некоторый цифровой интерфейс, в основном, с использованием собственного протокола. Как только Диспетчер и станция устанавливают сеанс управления, собственный протокол URGW используется как для сообщений управления, так и для аудиоканала. Оптимизация этой передачи сигналов по IP-сети является основной целью этой статьи.
Все части системы подключены к IP-сети, которая в действительности является своего рода WAN-соединением. В настоящей реализации URGW методы протокола SIP MESSAGE и INFO используются для инкапсуляции и передачи одноранговой сигнализации DP-RSC. Используется стандартный транспорт SIP UDP. Фактическая настройка уже используется в нескольких производственных развертываниях, но показала некоторые ограничения, когда используемый IP менее качественный или перегружен. Самая большая наблюдаемая проблема – неправильное управление ключами. Команда набора может быть выдана либо вручную диспетчером или удаленной стороной VoIP, либо в некоторых случаях даже автоматически системой VoIP, обнаруживающей конец речи (переключение). Здесь происходит фактическая адаптация полного / полудуплексного режима. Правильная и быстрая передача команды набора на радиостанцию имеет решающее значение для удобства голосовой связи конечного пользователя. Поскольку отраслевой партнер сейчас перестраивает весь URGW, перед нами была поставлена задача изучить все возможные настройки транспортных протоколов, чтобы дать окончательный ответ, какой из них лучше всего подходит для данного типа приложений.
В любом случае, главная цель – дать системе возможность правильно измерить (или угадать) время передачи. Использование системы Tx может указывать пользователю, когда безопасно начинать говорить, поэтому первые слова не будут обрезаны. Эта индикация обычно выполняется коротким звуковым сигналом в аудиоканале. На рисунке 3 показан подтвержденный вариант (E) для транспорта TCP. В IP-сетях доступно три транспортных протокола. UDP [1] – это ненадежная служба дейтаграмм без установления соединения. UDP должен использоваться с некоторым дополнительным механизмом обеспечения надежности. Остальные TCP [1] и SCTP [2] являются надежными протоколами, ориентированными на соединение. Мы полагаем, что читатель может угадать подробности установки по именам. Конечно, ключевая команда не единственная, которая должна передаваться при сигнализации DS-RSC, но, как показывает практический опыт, это единственная команда, имеющая серьезные проблемы на более низких уровнях качества IP-сети. Остальные команды просто менее требовательны в реальном времени.
Для протоколов UDP, TCP и SCTP мы использовали платформу INET [4]. Приложение для симуляции почти такое же, как и настоящее. Единственное отличие заключалось в том, что в симуляции не было потоков. Мы использовали свойство механизма имитации, то есть время движется вперед только тогда, когда происходит новое событие. Нет никаких задержек между уровнями связи, а обработка всех пакетов / сообщений происходит абсолютно параллельно и неблокируется. Мы доказали корреляцию результатов, полученных OMNET / INET, и живого транспорта сигналов в нашей предыдущей статье. Приложение имитирует один сценарий для всех транспортных настроек. Пользователь (клиент) нажимает кнопку нажатия каждый (настраиваемый) период времени, и противоположный сайт (сервер) информируется об этом событии. Эти два сайта соединены через простой сетевой канал, который имеет определенные параметры односторонней задержки и потери пакетов. Также можно настроить размер сообщения, чтобы можно было смоделировать проблемы с пропускной способностью. На рисунке показан экран печати симуляции OMNET, работающий в замедленном режиме.
L4PING APPLICATION
Настоящее приложение Linux также было создано вместе с имитационной моделью, чтобы доказать реальное поведение реализации транспортных протоколов Linux и сравнить его с результатами, полученными с помощью моделирования. Мы внутренне назвали это приложение L4ping. На уровне приложения пользователь отправляет запросы с определенной частотой (т. Е. Одно сообщение отправляется каждые 50 мс). Пользовательские запросы хранятся в буфере, который очищается выбранным транспортным уровнем (TCP, UDP или SCTP). Каждый транспортный уровень использует два потока, один для отправки сообщений и один для получения. Общее эффективное время транспортировки (от приложения к приложению) измеряется на прикладном уровне путем сравнения временных меток, хранящихся в качестве фактического содержимого сообщения. Однако в реальном мире есть некоторые сложности, которые не применяются в симуляции. Первый – это точное время. Событие симуляции не занимает времени, если оно явно не запрограммировано. В симуляции нет проблем обрабатывать входящие и исходящие пакеты одновременно. Чтобы минимизировать влияние задержки реальной обработки пакетов, L4ping пытается работать как можно более параллельно и неблокирующим. На уровне приложения существует два потока: первый только отправляет и ставит метки времени на уведомления, второй только получает и ставит метки времени на ответы и отправляет подтверждение, если ACK включен. На транспортном уровне также есть два потока, один для передачи и один для приема. Для UDP также существует другой поток, используемый для точного расчета времени, когда требуется подтверждение приложения.
Сетевой эмулятор Simena NE2000 [6] использовался для эмуляции настройки в реальной сети, как показано в моделировании OMNET ++. Эмулятор обеспечил понижение контролируемых параметров сети. Чтобы упростить правильное измерение времени и устранить проблему внутренней синхронизации времени двух машин, использовалась единая настройка машины. В этой настройке клиентское и серверное приложения были запущены на одном компьютере с использованием двух сетевых адаптеров Ethernet. Маршрутизация пакетов осуществлялась с использованием iptables. Была произведена двойная обработка пакетов на входе и выходе (до маршрутизации и после маршрутизации), поэтому пакеты, изначально предназначенные для локального интерфейса, теперь отправлялись на физический сетевой интерфейс. Эти пакеты в противном случае / обычно маршрутизировались бы только внутри ядра и даже не достигли уровня сети. Таким образом, могло бы произойти контролируемое понижение параметров сети, и простой временной метки времени машины было достаточно для правильного измерения времени поступления сообщений.
Единственная реальная информация, которая была передана, была метками времени. Остальные 200 байтов были просто фиктивными битами. Конечно, поскольку имитационная вычислительная мощность практически не ограничена в имитационной модели, фактический объем передаваемых данных не оказал влияния на результаты. 200 байтов было достаточно маленьким, так что длина сообщения также не оказала большого влияния на реальные измерения (ни в том, что касается обработки буферов или ограничений полосы пропускания). Чтобы ускорить измерение, сообщение генерировалось каждые 50 мс для UDP и каждые 800 мс для TCP (чтобы снизить уровень блокировки линии) и SCTP. Команды ввода обычно выдаются с частотой более одной секунды, поэтому в этом отношении не требуются. Иногда некоторые другие сигналы могут также передаваться по тому же каналу, поэтому использовалась немного более высокая частота генерации сообщений. Только некоторые наборы таблиц времени / потери сообщений показаны для экономии места. Полный набор данных может быть предоставлен по запросу.
<Р> а. Множественный UDP, нет приложения ACK Setup: это самый простой вариант, когда некоторый уровень надежности достигается путем одновременной отправки нескольких идентичных сообщений. ACK не используется на уровне приложения. Отправка нескольких копий одного и того же сообщения является пустой тратой пропускной способности, но в отношении ожидаемой частоты и размера сообщения мы не считаем это проблемой. Моделирование против реального соответствия приложения: результаты моделирования и реальных измерений показали почти 100% соответствие. Результаты: поскольку процесс доставки проходит всего один раз, время доставки точно соответствует задержке канала (конечно, можно учитывать только время для действительно доставленных сообщений). Таблица результатов времени даже не требуется показывать. С большей избыточностью потеря сообщений улучшается. Используя 5-кратное умножение сообщений, потери были, наконец, достаточно низкими, так что эта установка могла бы быть приемлемой для наших целей. (менее 1% для PER 0,4 и менее 3% для PER 0,5). ACK приложения отсутствует, поэтому фактическую Tx нужно будет угадывать, периодически измеряя RTT в боковом направлении, если выбрана эта настройка.
<Р> В. UDP с установкой ACK приложения: в этой настройке был принят показательный SIP-подобный откат для подтверждения уровня приложения [7]. Эта настройка была выбрана в основном для эмуляции фактической реализации URGW и изучения возможности улучшения реального приложения путем точной настройки уже используемого стека SIP. В наших измерениях таймеры T1 / TE были установлены на 50 мс (вместо значения SIP по умолчанию 500), поэтому процесс повторной передачи был более агрессивным.
<Р> С. Множественный UDP с приложением ACK Setup: это комбинация вариантов A и B. Как оригинальное, так и ACK-сообщение умножается в x раз, чтобы увеличить избыточность. Симуляция против реального соответствия приложения: результаты симуляции и реальных измерений показали отличное соответствие. Результаты: эта установка показала несколько лучшие средние времена доставки, поскольку избыточность явно устранила много повторных передач по сравнению с вариантом B. Измеренная средняя потеря сообщений была хорошей: менее 1% даже для PER 0,5 для 2-кратной избыточности и ноль для 3-кратное и более резервирование.
<Р> Д. TCP без приложения Настройка ACK: простой вариант транспорта TCP. TCP известен так называемой проблемой блокировки заголовков, когда речь идет о транспортировке отдельных независимых сообщений (т. Е. Сигнализации) [8]. Несмотря на это, мы хотели дать TCP возможность, так как в нашем приложении мы не ожидаем высокой частоты сообщений. (использовалась частота генерации сообщений 800 мс). Симуляция против соответствия реального приложения: имитационная модель показала сопоставимые результаты, чем реальное приложение. Как и ожидалось, в реальном мире блокировка проявляется несколько чаще, потому что реальное обслуживание стека TCP является более сложным, чем идеальное в имитационной модели. С другой стороны, в реальном приложении уже заблокированный поток все еще работает немного лучше, показывая меньшее общее среднее время. Результаты: Несмотря на довольно низкую скорость генерации сообщений, заголовок блокировки строк явно обнаружился, и, поскольку проблема носит кумулятивный характер (одно задержанное сообщение замедляет все последующие и т. Д.). Возникновение блокировки не на 100% коррелирует с ростом PER / LOSS. Даже для более высокой комбинации PER / потерь блокировка может происходить или не происходить, но как только она происходит, это TCP-соединение «теряется» до конца измерений. Не имеет смысла измерять фактическую потерю, так как TCP не допускает потери, и все сообщения будут доставлены в конце, но точки, где среднее измеренное время доставки превышает 10-кратную фактическую задержку линии, могут считаться неудовлетворительными. Эта настройка явно непригодна для нашего приложения.
<Р> Е. TCP с установкой ACK приложения: аналогично варианту D, но с включенным ACK приложения. Сообщения запроса и ACK используют один и тот же транспортный протокол TCP-соединения. ACK приложения может иметь смысл даже для транспорта TCP, поскольку он может помочь приложению измерить RTT и угадать Tx по нему. Симуляция против реального соответствия приложения: симуляция показала лучшие результаты, чем реальное измерение …
В пьесе есть много доказательств того, что Гамлет намеренно притворялся в припадках безумия, чтобы сбить с толку и дезориентировать короля и его служителей. Его откровенное
ЦИФРОВОЙ РЫНОК ДЛЯ ТОРГОВЛИ И РЕКЛАМЫ Ценность электронной коммерции через создание онлайн-рынков огромна для развивающихся стран, таких как Зимбабве, поскольку она может поддержать развитие местной
В истории было отмечено, что когда люди стремятся к власти, они используют свои слова и действия, чтобы продвигать себя. Будь то с помощью речей, актов